Adding a new column should be simple. In practice, it can block deploys, lock writes, and bring production to its knees if handled wrong. Databases are brutal about structure. The wrong migration can hang under load or cause downtime you didn’t plan for. That’s why you plan every change and test it like code.
The first step is choosing the right migration approach. In PostgreSQL and MySQL, adding a nullable column with a default can trigger a full table rewrite. When dealing with large datasets, avoid defaults in the initial statement. Instead, add the column as NULL, backfill in batches, and then set constraints after the data is in place. This reduces table locks and keeps transactions fast.
For distributed or sharded databases, you’ll need a phased rollout. Add the column without touching queries, then deploy application code that can read and write it, and only after that enforce constraints. Each stage should have monitoring in place to watch query patterns and ensure indexes are being used correctly.