Schema Change Safety Checklist
A safety checklist for applying production schema changes without locking tables or breaking applications. It covers change classification, backward compatibility, non-blocking DDL, expand-and-contract staging, and rollback. Use it to make every schema change a safe, pipeline-driven operation.
When to Use This Checklist
Use this checklist before applying any schema change to a production database. Schema changes are deceptively risky: a single ALTER can lock a large table, stall an application, or break code that expects the old shape. This checklist applies to every change, but its caution scales with how destructive the change is.
How to Use This Checklist
First classify the change. Additive changes (new nullable columns, new tables) are usually safe; transformative and destructive changes need staged rollouts. Confirm backward compatibility with the running application, because deploys are rarely instantaneous. Use non-blocking DDL and the expand-and-contract pattern to spread destructive changes across multiple deploys. Every required item is a guardrail against downtime or data loss; treat them as mandatory gates.
What Good Looks Like
A safe schema change is backward compatible, applied through non-blocking DDL, idempotent, and reversible. Destructive operations are split into expand, migrate, and contract phases across separate deploys, so the database and application are never out of step. The change is tested against production-sized data in staging, runs through the deploy pipeline rather than a manual console, and is watched through replication lag and latency metrics as it lands. Nothing about the change requires a maintenance window.
Common Pitfalls
The classic failure is a blocking ALTER on a large table that locks writes for minutes. Another is deploying a schema change and the dependent code together and assuming they apply atomically; in practice old and new code overlap. Dropping a column the previous release still reads causes immediate errors, which is why destructive changes must be staged. Teams also forget rollback: a forward-only migration with no down path leaves no recovery option if it misbehaves.
Related Resources
Use the expand-and-contract-migration-pattern for destructive changes and schema-evolution-schema-registry for compatibility discipline. Run migrations through pipeline-as-code, gate risky changes with feature-flag-best-practices, and verify outcomes with data-quality-management.