Adding a new column is one of the most common—but also most disruptive—database changes. With modern systems running 24/7, downtime is not an option. The wrong approach can lock tables, stall writes, or crash critical services. The right approach lets you evolve your schema in production without breaking a single query.
A new column is more than just an ALTER TABLE statement. It affects indexes, migrations, replication lag, and application code. The change must be sequenced. First, add the column with a default of NULL to avoid full table rewrites. Then, backfill data in controlled batches to prevent load spikes. Only after the column is fully populated should you add constraints or make it NOT NULL.
In distributed environments, schema changes must be coordinated across services. Code should be deployed to read from both the old and new column until the migration is complete. Feature flags can control rollout and fallback. Avoid adding indexes until the data is stable—building an index on a large table can saturate I/O and cause replicas to lag.