Adding a new column to a production database sounds simple. It’s not. A poorly planned change can lock tables, stall queries, and trigger downtime. The safe path is precise: pick the right migration strategy, understand the table size, and know how your database handles schema changes in real time.
In PostgreSQL, adding a nullable new column with a default is not free. It rewrites the table. For billions of rows, that’s hours of locks. The fix: add the new column without a default, backfill in batches, then set the default at the schema level. MySQL has similar constraints, though InnoDB’s instant add for some column types makes operations faster—until you hit an unsupported case.
Test the change in a replica. Measure the impact. Version SQL scripts. Use feature flags to gate code from reading the new column until it’s ready. If the column is part of a performance-critical path, index carefully. An index created inline during migration can overload I/O. Consider deferred indexing or partial indexes if your query patterns allow it.