The code waited. A schema change was coming. You needed a new column, and every second of downtime was a risk you couldn’t afford.
Adding a new column in production is deceptively simple. In small datasets, an ALTER TABLE ADD COLUMN runs fast. At scale, it can lock writes, block reads, and throttle your system. On databases like PostgreSQL, MySQL, or MariaDB, the default behavior can cause full table rewrites. The wrong command at the wrong time can cascade into outages.
The first step is precision in design. Decide the data type, nullability, and default value before touching production. Adding a nullable column without a default is often instant in modern versions of PostgreSQL and MySQL. Adding a non-null column with a default may rewrite the entire table unless you use version-specific features like PostgreSQL’s fast default in 11+. On older systems, break the change into two steps: add the column nullable, then backfill in small batches, then set NOT NULL once complete.
For MySQL with large InnoDB tables, use ALGORITHM=INSTANT if supported. This avoids table rebuilds and minimizes locks. Always check compatibility first; some column changes still need copy-based alterations. In PostgreSQL, avoid unnecessary locks with CONCURRENTLY where possible, but remember it’s not available for ADD COLUMN.