Database migration and DevOps practices bring version control and automation to schema changes, transforming ad-hoc SQL scripts into reliable, auditable deployments. Modern migration tools like Flyway, Liquibase, and Alembic allow teams to treat database changes as code, while zero-downtime patterns like expand-contract and shadow tables keep applications running during schema updates. The rise of database branching platforms (PlanetScale, Neon), GitOps workflows, and automated testing has shifted database changes from risky maintenance windows to continuous delivery pipelines. A key insight: backwards-compatible migrations are not optional—they're the foundation of zero-downtime deployments, requiring every breaking change to be split into expand (additive), migrate (dual-write), and contract (cleanup) phases.
What This Cheat Sheet Covers
This topic spans 14 focused tables and 173 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Migration Tool Versioning Conventions
Every migration tool needs a way to order changes and remember which have run, and the naming convention is where that contract lives. Notice the two broad camps: sequential numbering like Flyway's V1/V2 and Django's 0001, versus timestamp-based names that Rails, Prisma, and EF Core use to avoid collisions when teammates branch in parallel.
| Convention | Example | Description |
|---|---|---|
V1__initial_schema.sqlV2.1.3__add_orders_table.sql | • Versioned migrations with V prefix followed by version number, double underscore separator, and description • executed once in order | |
R__create_views.sqlR__stored_procedures.sql | • R prefix indicates repeatable migrations • re-executed whenever checksum changes • ideal for views, stored procedures, and functions | |
U1__undo_initial_schema.sql | • U prefix matches versioned migration number • contains rollback logic • requires Flyway Teams edition | |
id="1" author="dev"changeSet: | • Each changeset has unique id + author combination • executed once and tracked in DATABASECHANGELOG table • supports XML, YAML, JSON, and SQL formats | |
context: "dev, test"contexts: "prod" | • Conditional execution based on environment • allows same changelog to deploy different changes to dev vs. prod databases | |
labels: "feature-1, hotfix"labels: "v2.0" | • Fine-grained control over which changesets run • more flexible than contexts for feature flags and selective deployments |