The migration was breaking in production when the alert hit. A missing new column in the core table had brought writes to a standstill. Adding a new column sounds simple. In practice, it can break queries, block transactions, and lock tables for longer than you expect.
A new column is more than extra storage. It changes schema shape, index performance, and query plans. The wrong data type forces costly rewrites. A non-null column with no default stalls inserts until every row is backfilled. Even default values can be expensive when applied to millions of rows.
Before adding a new column, check the impact on disk, indexes, and replication lag. For large tables, online migration tools or rolling schema changes are safer. Use nullable columns or lightweight defaults to avoid table rewrites. Stage your changes: add the column, backfill in small batches, then enforce constraints. Always test migrations on production-size data, not a small test set.