The migration was due at midnight. The database was live. The plan was simple: add a new column, keep the system online, and avoid any downtime. Every decision from that point forward would affect both speed and stability.
A new column in a database sounds trivial. It is not. Schema changes are high-risk operations. On large datasets, a blocking ALTER TABLE can lock writes and stall production. Choosing the wrong migration method can trigger cascading failures, overload replicas, or delay deployments.
Before adding a new column, verify the storage engine, version-specific behavior, and available migration strategies. In MySQL, use instant DDL for non-blocking changes if supported. In PostgreSQL, adding a nullable column with a default can lock the table; instead, add it without defaults, then update in controlled batches. This avoids table rewrites and reduces transaction overhead.
Test the migration on a staging environment with production-like data volume. Measure query performance before and after. Check whether existing indexes, triggers, or constraints will be impacted. Create rollback scripts in case the change introduces regressions.