The database is fast, but the product team just dropped a new requirement: add a new column without downtime. You have millions of rows, active queries, and strict SLAs. Dropping traffic is not an option.
A new column seems simple until you face the constraints of production. Schema changes can lock tables, stall writes, and create replication lag. In high-load systems, poor execution here means degraded performance for hours. Choosing the right strategy defines whether your release goes smooth or burns a sprint on rollback.
First, define the column’s purpose. Is it nullable? Does it need a default value? Avoid applying default values that rewrite entire tables unless absolutely necessary. Adding a new column without locking requires careful use of non-blocking DDL. Many databases now support ADD COLUMN operations that modify metadata only, leaving existing rows untouched until accessed.
In PostgreSQL, adding a nullable column without a default is fast—metadata-only. Adding a default will rewrite the table in older versions but is optimized in 11+ to store the default only in the catalog. In MySQL, ALTER TABLE ... ADD COLUMN can be instant if you use InnoDB and meet conditions for fast DDL. Otherwise, expect a table copy. For distributed databases like CockroachDB, verify that schema changes propagate without blocking long-running transactions.