The migration hit production at 03:14. Within seconds, the schema changed. Rows complied, queries flowed, but the new column was live.
Adding a new column is simple in theory. In practice, it can stall deployments, lock tables, and add risk to critical systems. The goal is zero downtime and minimal performance impact. That means understanding your database, your workload, and the constraints your platform enforces.
Design starts with clarity. Decide if the new column allows nulls, has a default value, or requires backfilling. Defaults can trigger a rewrite of every row in large tables, which can mean minutes or hours of blocked writes. For high-throughput systems, that’s unacceptable. Instead, consider adding the column without a default, performing a background job to populate it, and applying constraints later.
For PostgreSQL, ALTER TABLE ADD COLUMN is fast when no default is set. Applying large defaults inline is where trouble starts. For MySQL, adding columns to InnoDB tables can still trigger a table copy depending on version and flags. Use ALGORITHM=INPLACE or ALGORITHM=INSTANT if available. Always confirm with EXPLAIN and review release notes to verify the path your database will take.