The migration stalled at one table. The schema change was simple: add a new column. Yet the cost of getting it wrong could be days of rollback pain.
A new column in a production database is not just an extra field. It changes the shape of the data, alters query performance, and can break downstream systems. The safest path is to treat every schema change as a deployment with its own release strategy.
Before adding the column, define its name, type, nullability, and default. Avoid vague names. Use types that fit the data exactly. A BOOLEAN that defaults to false is more explicit than a nullable integer flag. For large tables, adding a column can lock writes if not done carefully. Use online schema change tools or database-specific features to apply the update without blocking traffic.
Plan the rollout in phases. First, add the new column with a neutral default. Verify that it appears in query results without harming performance. Next, backfill data in small controlled batches to prevent spikes in load. Then update all dependent application code to use the new field. Only once everything is stable should you make the field required, if that was the end goal.