The build had failed for the third time that morning. A single change had rippled through your database schema, and now every test was broken. The solution was simple, but the cost of getting it wrong was high: add a new column.
A new column sounds trivial. It isn’t. Adding one touches your schema, your migrations, your code, and often your data pipelines. In production systems, a schema change can lock tables, trigger downtime, or cause subtle data corruption. Getting it right means treating it like a deployment, not just a script.
The first step is understanding the purpose of the new column. Is it nullable, or must it be filled immediately? A nullable column can be added in most modern databases without locking writes. A non-nullable column with a default value is more dangerous, as the database must rewrite every row. Consider splitting the migration into two steps: first add the column as nullable, then backfill values in small batches, and finally enforce constraints.
Second, think about indexes. If your new column will be queried often, add the index after the backfill. Adding an index on an empty or partially filled column can waste resources or mask write performance issues until it’s too late.