The sprint was set. The schema was locked. But product changed the spec—again. You need a new column. Not in a week. Now.
Adding a new column in production is never as simple as it looks in migration scripts. Schema changes impact uptime, indexing, replication lag, and query performance. A careless ALTER TABLE can lock writes, block reads, or spike load. The faster the database, the more it punishes sloppy DDL.
The first step: choose the right migration strategy for the table size and workload. For small tables, an online migration may be unnecessary, but large, high-traffic tables demand tools that avoid locks. PostgreSQL users might reach for ALTER TABLE ... ADD COLUMN with a default value, but that write can be costly without DEFAULT NULL and a follow-up batch update. MySQL veterans know to check for ALGORITHM=INPLACE or use ghost table strategies with pt-online-schema-change or gh-ost.
Next: consider indexes and constraints. If your new column needs a unique index or foreign key, defer adding these until after the column is live with data populated. This avoids the overhead of constraint checks during large backfills.