The migration failed at 2 a.m. because one column was missing. It should have been a simple addition: a new column in a table that thousands of requests hit every second. Instead, it brought the deployment to a halt.
Adding a new column is one of the most common database schema changes. Done carelessly, it can lock tables, block writes, or trigger long-running migrations that hurt latency. Done well, it’s invisible to the user and gives you the data shape you need without risk.
The first step is to define the new column with the correct type and constraints. Avoid adding NOT NULL columns with default values on large datasets; this can cause a full table rewrite. Instead, add the column as nullable, backfill the data in small batches, then apply constraints and defaults.
When running migrations in production, make them idempotent. Check if the new column already exists before adding it. This prevents failures in repeated deploys and keeps CI/CD pipelines clean. Use transactional DDL if supported, but be aware that some database engines treat ALTER TABLE operations differently.