The query ran clean, but the result broke. The table needed a new column. No delays. No migrations waiting in a backlog. Just the change, live, and part of production without risk.
Adding a new column in a database is simple in theory but takes precision in practice. The wrong type, the wrong default, or an overlooked constraint can trigger lock contention, slow writes, or fail under load. The operation must fit the schema, the query patterns, and the application code.
In PostgreSQL, ALTER TABLE ADD COLUMN is transactional. But on large datasets, it may lock writes. MySQL behaves differently, especially with older storage engines, where adding a column may rewrite the whole table. Even with online DDL, indexes and foreign keys can slow the process or block concurrent changes.
The safest path is to plan for backwards compatibility. Add the new column with a nullable default so existing reads and writes don’t fail. Deploy code that can work with both the old schema and the new. Backfill data in controlled batches. Then toggle constraints or defaults once the data matches expectations.