The table was live in production when the request came in: add a new column. No staging. No downtime. No room for error.
A new column can look simple in a migration file, but the reality depends on database size, storage engine, and locking behavior. In PostgreSQL, adding certain column types with defaults can lock the table and block writes. MySQL behaves differently but comes with its own caveats, especially under high concurrency. Knowing these differences is the first step to safe schema changes.
Plan the change in two steps. First, add the new column without a default or constraint. This operation is usually fast and non-blocking. Second, backfill the column in batches to avoid long locks and heavy I/O spikes. Once data is in place, add constraints or indexes with minimal disruption.
For large datasets, monitor the operation with database metrics. Watch active connections, lock waits, and replication lag. Schedule the migration during low-traffic windows if possible. If the platform requires zero downtime, test the migration on a clone with production-scale data before touching live systems.