The table was live in production when the alert hit. You needed a new column, and you needed it now. No downtime. No broken queries. No rollback nightmares.
Adding a new column sounds simple until you face billions of rows, global traffic, and fragile legacy code. The wrong migration approach can lock your table, spike CPU, and trigger a cascade of failures. You need a method that is fast, safe, and zero-impact on active reads and writes.
In SQL, ALTER TABLE is the standard way to add a new column. For small datasets, it works without trouble. On large hot tables, a direct ALTER can block for minutes or hours, or worse, cause latency across the system. Production databases need an online schema change process. Tools like pt-online-schema-change or gh-ost create a shadow copy of the table, apply the new column definition, and swap it in without locking writes.
For Postgres, use ALTER TABLE ADD COLUMN with a NULL default when possible. Avoid setting a non-null default in the same statement, as it rewrites the entire table. Instead, add the column nullable, then backfill in controlled batches, and finally enforce constraints. For MySQL, similar rules apply: keep the change lightweight, avoid operations that rebuild the table in a single transaction, and test on a production-sized clone.