A single missing column can break queries, corrupt data, and stall deploys. Adding a new column to a production database is not complicated, but timing, performance, and safety matter. Done wrong, it locks tables and blocks writes. Done right, it rolls out without users noticing.
When you create a new column, decide if it should be nullable. Non-null columns need defaults. Defaults on large tables can trigger full table rewrites and downtime. If the column must be backfilled, batch updates in small chunks to avoid load spikes.
Use ALTER TABLE with care. In PostgreSQL, some column changes are fast metadata updates. Others, like adding a column with a non-constant default, require rewriting every row. In MySQL, adding a new column can be instant with ALGORITHM=INSTANT—but only for certain cases. Test DDL against a staging database with production-scale data. Measure lock times.
Consider schema versioning in your migrations. Deploy the new column first without constraints. Fill the data in background jobs. Then add indexes or constraints in a later release. This reduces risk and makes rollbacks possible.