The database stopped responding. You scan the logs. One query is slower than the rest. A missing index is part of it, but the real problem is the schema. You need a new column. Not next sprint. Now.
Adding a new column is simple in theory. In production, it’s never trivial. Schema changes lock tables, block writes, and can cascade into outages. The right approach depends on your database, the column type, and whether you must backfill existing rows. Plan the change before typing ALTER TABLE.
For relational databases, the safest pattern is staged migration. First, add the new column as nullable to avoid rewriting all rows immediately. Deploy this change separately from the code that writes or reads the column. Second, run a backfill in batches to control load. Keep each batch small to avoid table locks. Monitor replication lag. Only after the backfill is complete should you enforce constraints like NOT NULL or default values.
In PostgreSQL, ADD COLUMN with a default can rewrite the full table if not handled carefully. In MySQL, adding a column to large tables without ALGORITHM=INPLACE can lock writes. In distributed databases, schema changes may propagate unevenly, so build in validation.