Adding a new column sounds simple. It rarely is. Schema changes can trigger downtime, lock tables, strain replication, and break code paths you forgot existed. The wrong migration strategy at scale can bring a production system to a halt.
When you add a new column in SQL, you alter the schema. In MySQL or PostgreSQL, ALTER TABLE ... ADD COLUMN is the syntax. But the command is only the surface. The details decide whether your migration is instant or catastrophic.
First, know your database engine’s locking behavior. Some engines block writes during schema changes. Others, with online DDL, can add columns without blocking, but may still cause replication lag. Always read the fine print in your version’s documentation before running migrations in production.
Second, set defaults carefully. Adding a new column with a non-null default in a large table can rewrite every row and hammer your I/O. If possible, add the column as nullable with no default, backfill values in batches, then set constraints in a second migration. This avoids long locks and lets you monitor performance as data changes.