The query ran in milliseconds, but the schema was already wrong. You needed a new column, and you needed it without downtime.
Adding a new column is simple until it’s not. In production, schema changes can block writes, lock tables, or cause replication lag. The approach you choose defines whether users notice or the change slips in seamlessly.
First, decide if the new column is nullable or has a default value. Nullable additions are cheap in most relational databases and usually run instantly. Non-nullable columns with defaults can rewrite the whole table, which is expensive. In PostgreSQL 11+, adding a column with a constant default writes metadata only—safe for large datasets. MySQL’s ALTER TABLE still copies data in many cases unless you use ALGORITHM=INSTANT in supported versions.
Next, plan for application compatibility. Deploy code that can read and write with the old schema before the column exists. Then add the new column. Finally, deploy code that uses it. This migration pattern prevents runtime errors during rolling upgrades.