The schema had to change, and the only way forward was to add a new column. One change, but it carried weight. It would alter the queries, shift the indexes, and ripple through the codebase. Done wrong, it could stall production. Done right, it could unlock new capabilities without breaking a single deploy.
Adding a new column in a database seems simple on the surface: write an ALTER TABLE statement, set the column name, pick a type. But for large systems, every decision matters. Will it allow null values? Should it have a default? Will it need an index from day one, or should indexing wait until after the historical backfill? These questions decide whether migrations run in minutes or burn hours under lock contention.
On PostgreSQL, ALTER TABLE ADD COLUMN with a default can rewrite the entire table. In high-traffic environments, that’s dangerous. A safer pattern is to add the column without a default, then backfill in small batches. Once complete, set the default for future inserts. MySQL has similar concerns. Depending on the engine and version, adding even one column may require a full table copy. Check documentation and test in staging before touching production data.