dbmate and Sqitch
You have a database and a problem most frameworks pretend doesn't exist: your schema changes over time, and those changes have to travel from your laptop to staging to production in the same order, every time, without anyone running a SQL file by hand and hoping. You don't have an ORM. You don't want one. You want plain SQL, version-controlled, applied predictably. That's exactly the gap these two tools fill, and they fill it in two very different ways.
This guide gives you a working mental model of both, then shows you the day-to-day commands, then walks into the parts that bite people in production.
How to read this
Read it in order the first time. Phase 1 builds the mental model that makes everything else obvious: both tools turn schema change into ordered, repeatable SQL, but dbmate orders by timestamp and Sqitch orders by a dependency graph. Phase 2 is the muscle memory: creating, applying, and rolling back changes with each tool. Phase 3 is the production reality: drift, failed deploys mid-flight, verify scripts, and the choices you'll regret if you skip them.
If you already use one tool and are eyeing the other, you can skip to Phase 2 and read the two halves side by side.
The phases
- Phase 1: Two ways to order change - what these tools actually are, and why timestamps and dependency graphs are different answers to the same question.
- Phase 2: The everyday loop - create, apply, and revert migrations with dbmate and Sqitch, command by command.
- Phase 3: Production reality - drift, half-applied deploys, verify scripts, and the gotchas that cost you a weekend.