The database needs a new column, and the change has to happen fast—with zero downtime, no broken queries, and no surprises in production.
Adding a new column is never just “ALTER TABLE.” It’s a controlled event. It requires understanding constraints, indexes, locks, and data distribution. Even a simple boolean can escalate into migration hell if managed poorly.
First, assess the workload on the target table. High write rates? Large row counts? You may need to run migrations in batches or use a backfill strategy. In Postgres, adding a column with a default value causes a full table rewrite. That can block writes and spike replication lag. Avoid defaults at creation. Add the column as nullable, then populate values in stages.
Enforce type precision early. A poorly chosen type will become technical debt baked into every query. Consider future growth, cardinality, and query patterns before committing.
If the new column is indexed, delay index creation until after the data is filled. Building an index on an empty column is faster, but it’s also wasted effort if data changes during the fill phase.