The database schema had to change, and the deadline was hours away. You needed a new column. You didn’t need bureaucracy. You needed it live.
A new column seems simple: add it, deploy, done. But in real systems, this step can block releases, lock tables, or cause migrations to time out. The wrong command can freeze writes, spike CPU, or cause downtime at scale. The right process minimizes risk and cost.
When adding a new column in PostgreSQL or MySQL, choose operations that are metadata-only when possible. For PostgreSQL, adding a nullable column without a default is instant. Adding a default with a constant value will still rewrite the table in older versions, so check your engine’s behavior. In MySQL, use ALGORITHM=INPLACE when you can to avoid copy-based table rebuilds. Always run migrations in transactions if your engine supports them.
For large tables, break the change into steps. First, add the new column as nullable without a default. Then backfill in small batches to avoid locking. Finally, set constraints or defaults. This phased approach prevents long locks and lets you monitor load between steps.