Adding a new column sounds simple, but it’s the kind of change that can break production if you don’t handle it with precision. The database doesn’t care about your deadlines, your release window, or the fact that you only have a five-minute maintenance slot. It will accept a bad migration the same way it accepts a good one—until queries fail and users complain.
A new column in a relational database is more than just ALTER TABLE. You have to consider nullability, default values, indexes, constraints, and the impact on application code. Adding a nullable column might be safe for small tables, but for large data sets, the operation can lock the table and block writes. Adding a non-nullable column with a default requires physical writes to every row, which can cause performance degradation or downtime.
When the new column will be used by live traffic, plan it as a staged rollout. First, deploy the schema change in a non-breaking way—nullable, with no default or index. Then backfill the data in batches, monitoring metrics after each batch. Once backfill is complete, enforce constraints or indexes in a second migration. This reduces locking time and avoids unexpected failures.