The migration failed. The logs showed why—someone forgot to add a new column.
Adding a new column sounds simple, but in production systems, it can cause lock-ups, slow queries, or even downtime. The key is to do it without breaking anything. In SQL databases, adding a column with ALTER TABLE can block reads and writes if not handled with care. In NoSQL, an implicit new column might need updates to schema validation or serialization code.
When you add a new column, decide if it should allow NULL, have a default value, or require backfilling. Setting a default on a large table can rewrite every row, which can lock the table. In PostgreSQL, adding a column with a DEFAULT and NOT NULL in one step will rewrite the table before version 11; newer versions optimize this, but test first. In MySQL, column order matters and evolving schemas require attention to storage engines and replication lag.
For zero-downtime migrations, use feature flags paired with background jobs. Add the column as nullable. Deploy code that writes to both old and new columns. Backfill in small batches using an indexed key. After verification, switch reads to the new column. Finally, remove fallback logic. Each step should be reversible.