Adding a new column seems simple. In SQL, it’s often a single ALTER TABLE command. But when this happens in production, it’s rarely just syntax. You need to think about locks, migration speed, and backward compatibility. Schema changes run the risk of blocking reads and writes. On large datasets, it can spike CPU and I/O, stall replication, and trigger alerts.
Always measure the cost. In PostgreSQL, ALTER TABLE ADD COLUMN with a default value rewrites the whole table. If you can, add the new column as NULL first, then update it in batches. In MySQL, a schema change may require a full table copy unless you run it with ALGORITHM=INPLACE. For distributed databases, schema changes cascade differently across nodes—read the vendor docs before you execute.
Application code needs to handle both the old and new schema during rollout. Deploy code that can work if the column is missing or empty. Only after the column is in place and populated should you drop migration guards. This allows zero downtime changes and avoids race conditions during deploy.