The table waits, but the data has changed. You need a new column. You need it without downtime, without breaking queries, without risking corrupt rows. Schema changes are simple in theory and dangerous in practice. Done wrong, a new column can lock writes, crash services, or cause cascading failures. Done right, it slides into production like it was always there.
Adding a new column to a database table starts with knowing your engine. In PostgreSQL, ALTER TABLE ADD COLUMN is fast for nullable columns without defaults, because it just updates metadata. In MySQL, behavior depends on the storage engine and version; InnoDB can handle many additions instantly, but older versions still rewrite the table. With large datasets, rewriting means long locks and blocked transactions.
Set defaults carefully. Adding a default with a NOT NULL constraint forces the engine to fill every row, which can be catastrophic on large tables. The safer path: add the new column as nullable, deploy, backfill in small batches, then add constraints in a later migration. That approach avoids locking and keeps services available.
Indexing a new column is also costly. Online index creation or concurrent indexing is critical for high traffic systems. Without it, you risk blocking reads and writes for minutes or hours. Always measure the real runtime on a staging copy of production data before scheduling.