The migration was running hot when the request came in: add a new column. No delay. No scope creep. Just one precise change in a schema that already powered millions of transactions every day.
Adding a new column sounds simple—until you factor in live traffic, zero-downtime guarantees, and strict SLAs. In relational databases, a new column alters the table definition. In PostgreSQL or MySQL, this triggers metadata updates; in some cases, it can lock the table. For large datasets, this can stall reads and writes. Even with modern engines, careless ALTER TABLE commands can cause replication lag or break failover strategies.
The safe approach depends on your constraints. If you can tolerate brief locks, a standard ALTER TABLE ADD COLUMN works. For massive tables under constant load, use an online schema change tool like pt-online-schema-change or native features like ALTER TABLE ... ADD COLUMN with ONLINE in MySQL or ALTER TABLE ... ADD COLUMN combined with NOT VALID constraints in PostgreSQL. These strategies write the new structure without blocking queries or degrading performance.
Always consider defaults. In many databases, adding a column with a default value rewrites every row, causing heavy I/O. Instead, add the column with NULL allowed, then backfill in controlled batches. Once complete, alter the column to set the default and apply constraints atomically. This pattern reduces migration risk and avoids full-table locks.