The table was running hot, queries stacked up, and the schema could not keep pace. You needed a new column, and you needed it without wrecking uptime.
A new column sounds simple. ALTER TABLE, add the field, deploy. But the wrong move can lock writes, spike latency, or stall production. The impact scales with the size of your table and the database engine you run. MySQL, PostgreSQL, and other systems all handle schema changes differently, but the risks are the same: blocking, replication lag, or silent failures.
The safest path is to treat the new column as a first-class migration task. Plan for it. In PostgreSQL, adding a nullable column without a default is fast because it updates only metadata. Adding a column with a default will rewrite the table—slow for big data sets. MySQL’s behavior depends on the engine and version; InnoDB with instant DDL can add columns without a full table copy, but older versions cannot.
In production, always test the migration on a replica. Measure how long it takes. Monitor disk usage during the operation. For large tables, online schema change tools like pg_online_schema_change or gh-ost let you add the new column without locking the main table. Script the change, run it during low load, and keep alerting in place until it finishes.