Adding a new column should be simple. In practice, it can break your app, corrupt your data, or block your deploy if you don’t plan it right. Schema changes like adding columns touch production data. That means downtime risk, lock contention, and performance spikes.
A new column in SQL can be added with a direct ALTER TABLE statement. This works on small datasets but can be costly on large tables. Some databases lock the whole table while adding the column. Others copy the data under the hood. Either can slow queries or block writes.
Best practice is to add columns in a way that avoids blocking and preserves compatibility. Deploy the column without changing existing queries. Backfill data in small batches. Only when the new data is ready should you update application code to use it.
In PostgreSQL, adding a nullable column with no default is fast. Setting a non-null default can rewrite the table, so add the column first, then update rows after. MySQL behaves differently — even adding a nullable column may lock in older versions. Always check your database version and documentation before running changes in production.