Adding a new column to a production database is simple in theory. In practice, it can break your application, block writes, and trigger downtime if done carelessly. The right process makes the change fast, safe, and reversible. The wrong process turns it into an outage.
A new column changes schema, storage, and sometimes queries. On small datasets, it can be instant. On large tables with millions of rows, it can lock the table and stall requests. Engineers run into this with relational databases like PostgreSQL, MySQL, and MariaDB when schema migrations run on live systems.
The safest approach is to create the new column in a way that avoids full-table rewrites. In PostgreSQL, adding a nullable column without a default is nearly instant. If a default value is required, set it in a later update to prevent locking. Use a migration tool that supports transactional DDL when the database allows it.
Index creation for the new column is a separate step. An index on a large table can take minutes or hours. Use concurrent index operations when supported, so reads and writes continue. Profile queries before adding indexes; not every new column needs one.