The migration was supposed to be simple. Then the schema changed, and you had to add a new column.
Adding a new column should not break your system. Yet in real deployments, schema changes are where production outages often start. A single blocking migration can lock tables, delay queries, or invalidate cached data. Avoiding these failures starts with how you plan, execute, and verify the change.
When you add a new column to a relational database, think in terms of atomic, backward-compatible steps. First, create the column with a default of NULL. This avoids rewriting the entire table on creation. Update application code to handle both existing and new rows. Only after the deployment is stable should you backfill data. For large datasets, batch the updates to keep locks short and avoid overwhelming I/O.
Use feature flags or conditional logic to gate writes to the new column. This lets you roll changes forward without downtime and roll back quickly if needed. Monitor performance, especially for sequential scans triggered by missing indexes. When indexing the new column, build the index concurrently to prevent blocking the main workload.