Adding a new column should be fast, safe, and predictable. In real systems, it can be a risk. A careless migration can freeze production, slow queries, or corrupt data. That’s why the way you create a new column matters as much as the column itself.
The core sequence is simple: define the new column, choose the right data type, set defaults if needed, and migrate without downtime. Yet simplicity on the surface hides sharp edges underneath. A blocking ALTER TABLE can lock writes. An incorrect default can backfill millions of rows, spiking CPU and I/O. If you run sharded or distributed databases, the problem compounds—one schema change becomes hundreds.
Use non-blocking schema change tools when possible. For PostgreSQL, avoid adding DEFAULT values in the same transaction as the new column. For MySQL, consider pt-online-schema-change or native online DDL. Test migrations against production-like data volumes. Measure both read and write performance during the change.