The table was live in production when the request came: add a new column. No staging delays. No multi-week planning. Just the change, in real time, without breaking anything.
Adding a new column should be simple. In practice, it can take hours or even days if the database is large, the schema is locked down, or the migration system is fragile. The challenge is not the SQL—ALTER TABLE ... ADD COLUMN is trivial. The challenge is executing it safely under load, with zero downtime, and keeping the rest of the system in sync.
A new column changes more than the table. It touches the API layer, the ORM models, the migrations repository, and maybe the cache layer. Without a clear plan, the result can be inconsistent reads, failed writes, or worse—production incidents.
The safest process is atomic and forward-compatible. First, deploy the schema change in a way that does not block reads or writes. On PostgreSQL, this can be near-instant if the column is nullable and has no default. Avoid named constraints or heavy index creation during the same operation. On MySQL, be aware of storage engine specifics; some ALTER operations lock the table.