Adding a new column should be simple. In practice, it can be dangerous. Schema changes touch live data. They can lock tables, block writes, and stall production systems. A single misstep can leak latency into every request.
When you add a new column in SQL, the exact behavior depends on the database engine. In PostgreSQL, adding a nullable column with no default is fast—instant for most cases—because it only updates metadata. Add a column with a non-null default, and the engine will rewrite the table. On large datasets, that can mean minutes or hours of downtime unless you mitigate it. MySQL behaves differently. InnoDB may rewrite the table even for metadata-only changes unless you use ALGORITHM=INSTANT in supported versions.
In production, you must plan the new column migration in stages. First, deploy the schema change in a way that avoids full rewrites. Use nullable columns without a default. Backfill values in small batches to prevent load spikes. Finally, apply constraints or defaults after data is in place. Zero-downtime migration tools like pt-online-schema-change or gh-ost can help, but only with strict testing.