The table was ready, but the data was wrong. You needed a new column, and you needed it without breaking production.
Adding a new column to a database sounds simple, but the wrong approach can lock tables, block queries, and throw users into error states. The safest way is to design the change so it’s fast, reversible, and deployable with zero downtime.
First, know your schema migration strategy. With relational databases like PostgreSQL or MySQL, adding a nullable column or one with a default that’s not computed is usually safe. But adding a column with a non-null constraint and a default value that triggers a full table rewrite will stall your system. Instead, add the column as nullable, backfill data in small batches, then set constraints after the fact.
Schema changes should be deployed in phases. Step one: add the new column in a migration script that runs quickly. Step two: update application code to write to the new column while still reading from the old one. Step three: backfill historical data using a job that’s throttled to avoid saturating I/O and locking rows. Step four: swap reads to the new column once fully populated, then drop the old column if no longer needed. This pattern reduces deployment risk and improves rollback options.