The database was fast until the schema changed. Now reports lag, queries stall, and the app stutters under load. The problem started with a single need: a new column.
Adding a new column sounds trivial. In code, it’s a single line. In production, it can block writes, lock tables, and force long-running migrations. On small datasets, you might not notice. On large tables with millions of rows, the wrong approach can impact uptime and revenue.
To add a new column safely, think in two parts: schema evolution and data backfill. Schema evolution is about creating the column in a way that doesn’t block operations. Avoid default values on the initial ALTER TABLE if your database locks during DDL changes. Instead, add the column as NULL, then update defaults in a later step. This minimizes lock time and risk.
Data backfill should happen in chunks. A single massive update can hold locks and flood I/O. Use batched updates that commit after small sets of rows. Many teams use scripts with transaction limits or database-native features like SET statement_timeout to keep operations safe.