Adding a new column is one of the most common schema changes in modern development. Done right, it is fast, safe, and easy to roll out. Done wrong, it can lock tables, block queries, or trigger costly downtime. Whether you run migrations on PostgreSQL, MySQL, or a distributed system like CockroachDB, you need to understand the impact.
A new column changes the shape of your data. Even if it starts as NULL for every row, the database engine must still write metadata to track it. On small datasets, this is trivial. On large live databases, a blocking ALTER TABLE can freeze writes and delay reads. Many teams mitigate this by adding the column without defaults, backfilling in small batches, and then setting constraints or defaults afterward.
In PostgreSQL, ALTER TABLE ADD COLUMN is fast if you avoid defaults that require rewriting the whole table. In MySQL, the speed depends heavily on the storage engine and the schema change method. Tools like pt-online-schema-change or gh-ost can run migrations without locking the table. Distributed databases may use online schema changes natively, but you still need to monitor replication lag and query performance.