A schema change is never just a schema change. Adding a new column touches storage, indexes, queries, and application logic. It can break migrations in production if handled without care. The goal is to ship the change fast, without downtime, and without corrupting data.
To add a new column safely, start by creating it as nullable with a default value if needed. This avoids locking the entire table for writes. In systems like PostgreSQL, certain operations are instant; others can block traffic. Know your database’s DDL characteristics before running anything in production.
Use feature flags to decouple the schema change from the code that writes to the column. Deploy the schema first. Then update the application to read from and write to the new column. This two-step release prevents race conditions and lets you roll back without a second migration.
For large datasets, backfill values in small batches. This avoids replication lag and keeps queries responsive. Monitor the CPU, I/O, and replication delay during the process. Treat these operations as part of your deploy pipeline, not as background chores.