The migration finished at 3:12 a.m., but the logs told a different story. A missing new column in the core table had broken the build, and every downstream service was waiting for a schema update that never landed.
Adding a new column is one of the most common database changes, yet it’s also a frequent cause of outages and failed deployments. The process seems simple: alter the table, define the column type, set defaults if needed. In production, it’s rarely that clean. Locking during writes, background index builds, and API compatibility all have to be considered to prevent downtime.
When you add a new column in SQL — whether in PostgreSQL, MySQL, or a managed cloud service — you must ensure it won’t block transactions or cause data drift. Backfilling existing rows can take seconds in small datasets, but millions of records can turn it into hours. That’s when deployment strategies matter.
Use ALTER TABLE with care. For PostgreSQL, adding a nullable column without a default is fastest because it avoids a table rewrite. For MySQL, watch for instant add capabilities in newer versions. If you need a default value, consider a two-step deployment: first add the column as null, then update in small batches to avoid locking. This reduces impact on live traffic.