Adding a new column is simple—if you control the database, the load, and the downtime. But reality is rarely that clean. Lock contention, migrations that run for hours, cascading changes to APIs, and the fear of data loss turn one ALTER TABLE into a risk factor for the whole system.
A new column is never just a new column. It’s a schema change, storage reallocation, indexing decisions, and data backfill. Do you add it as nullable to ship fast, or do you default it and rewrite old records? Do you push it first without application logic or roll out code that writes both old and new fields in parallel? These steps are not optional—they’re survival tactics for production systems.
In PostgreSQL, a new column with a default value can rewrite the entire table. On MySQL, large table alters can lock writes for the duration of the operation. These database-specific behaviors define whether your deployment is instant or it wakes up your pager. The right path might be online DDL tools like pt-online-schema-change or gh-ost, using shadow copies of data to apply changes without blocking traffic.