It wasn’t the database engine’s fault. The problem was in the process — the way the schema was altered, the way defaults were applied, and the way indexes were added before load testing. Adding a new column sounds simple, but in production systems, it can expose every weak spot in your data model.
A new column changes the shape of your table. It can alter query plans. It can force full-table rewrites if defaults are non-null and stored. It can break ETL jobs that assume fixed schemas. For relational databases like PostgreSQL or MySQL, the time cost depends on storage configuration, row format, and whether concurrent reads can continue during the change.
Safe deployment starts with understanding the write path. In most cases:
- Add the column as nullable.
- Deploy without defaults that trigger rewrites.
- Backfill data in controlled batches.
- Apply constraints and indexes after the backfill.
For distributed databases, adding a new column won’t necessarily block traffic, but schema changes must align across all nodes. Schema drift can lead to inconsistent reads and silent write failures if replication lags. Always verify schema state at the cluster level before routing writes to it.