Sqitch: Database Change Management Without an ORM

What Sqitch solves that a numbered migration folder does not

Most migration tools assume the schema is a byproduct of application code. Sqitch assumes the opposite. It is a standalone change management system with no opinions about your database engine, application framework, or development environment, and changes are implemented as scripts native to the selected engine. A PostgreSQL project gets SQL scripts for psql; an Oracle project gets SQL*Plus scripts. Nothing is generated, nothing is translated through a DSL.

The second difference is ordering. Changes may declare dependencies on other changes, including changes from other Sqitch projects, so a commit that lands out of order in version control still deploys in the correct sequence. The plan file holds those declarations and Sqitch uses a Merkle tree pattern, similar to Git, to compute the deployment order. That means you do not have to number changes, and the tool does not care how you name them.

The audience is narrow and specific: teams that treat SQL as the artifact, that want the same change set applied to a development laptop and a production cluster, and that have been burned by a migration table that says a change ran when it only half ran. Sqitch adds a verify step alongside deploy and revert, which is where that pain usually sits.

The plan file, the registry, and what actually runs

A Sqitch project has three moving parts. The plan file lists changes and tags in dependency order. Each change has scripts on disk, typically a deploy script, a revert script and a verify script. The registry is a set of tables Sqitch creates inside the target database to record what has been applied.

Deployment walks the plan, resolves dependencies, and executes the deploy script for each change not yet in the registry. Reverting walks backward and runs the revert script. Verification runs the verify script, which is your assertion about the state of the database after the change, not a checksum of the file. That distinction matters: Sqitch is not comparing your scripts to what ran. It is asking the database whether the change took effect.

Because dependencies are explicit, a change in one repository can depend on a change in another. That is unusual among migration tools and it is the reason Sqitch suits multi-repository systems where a shared schema fragment is owned by a different team. The cost is that the plan file becomes a second thing to maintain and review, and a merge conflict in it is a real conflict about ordering, not a cosmetic one.

Installing Sqitch and adding a first change

The README gives a distribution install using the Perl build script. Run these from the unpacked distribution directory; the build step compiles and the test step runs the suite before installation.

perl Build.PL
./Build installdeps
./Build
./Build test
./Build install

If you would rather not touch the system Perl, the README documents a self-contained bundle built with the Menlo CPAN client. Feature names correspond to supported engines, so you only pull in the drivers you need.

cpanm Menlo::CLI::Compat
./Build bundle --install_base sqitch_bundle --with postgres --with sqlite

After that, Sqitch runs from ./sqitch_bundle/bin/sqitch. The README also points to platform-specific instructions for Debian- and RedHat-derived Linux distributions and Windows, and the repository carries a Docker badge, so a container image is part of the published surface even though the README does not spell out the run command.

The README lists the tutorials as the best place to start, with separate introductions for PostgreSQL, YugabyteDB and CockroachDB, SQLite, Oracle, MySQL, Firebird, Vertica, Exasol and Snowflake. Work through the one matching your engine before you touch a production database, because the plan file and the registry tables are easier to understand once you have seen a deploy and a revert in sequence.

Where Sqitch is the wrong tool

Sqitch does not diff your schema. If your workflow is to change a model class and have the tool emit the ALTER statements, Sqitch will not do that, and no amount of plan file discipline will make it. You write the DDL.

It also does not manage data migrations for you beyond running whatever SQL you put in the scripts. A backfill that needs batching, throttling or a resumable cursor is your code inside a deploy script, and a long-running one will hold the deployment open.

The verify step is only as good as what you write. Sqitch runs your verify script; it does not infer correctness. A project that ships empty verify scripts gets the same green result as one with real assertions, which is a silent failure mode worth knowing about before you trust a passing verify in CI.

Finally, the engine list is broad but version-bounded. The README states PostgreSQL 8.4+, YugabyteDB 2.6+, CockroachDB 21+, SQLite 3.8.6+, MySQL 5.1+, MariaDB 10.0+, Oracle 10g+, Firebird 2.0+, Vertica 7.2+, Exasol 6.0+, Snowflake, and ClickHouse 25.8+. An engine outside that list, or a version below the floor, is not a supported target.

Sqitch against Flyway and Liquibase

Flyway and Liquibase are the two tools people most often weigh against Sqitch, and the split is about who owns the SQL.

Liquibase centers on a changelog written in XML, YAML, JSON or SQL, with an abstraction layer that can generate database-specific SQL from a generic description. That abstraction is the selling point and the cost: you describe the change once and let the tool translate, which helps when one project must target several engines, and hurts when you need an engine-specific feature that the abstraction does not model. Sqitch takes the opposite position. There is no abstraction, so a PostgreSQL change is PostgreSQL SQL and a Snowflake change is Snowflake SQL, and you maintain them separately.

Flyway is closer to Sqitch in spirit: versioned SQL migrations, a schema history table, a command-line tool. The difference is the ordering model. Flyway relies on version numbers and naming conventions, while Sqitch relies on declared dependencies resolved through the plan file and the Merkle tree. If you have ever had two branches both claim version 42, the Sqitch model is the answer. If you want a filename to be the whole story, Flyway is simpler.

Neither alternative is wrong. The question is whether your team wants a tool that reads your SQL or one that writes it.

Licence, releases and what upgrades cost you

Sqitch is MIT licensed, copyright 2012-2026 David E. Wheeler and 2012-2021 iovation Inc. The grant is permissive: use, copy, modify, merge, publish, distribute, sublicense and sell, provided the copyright notice and permission notice travel with the software. The software is provided as is, without warranty. That is a licence text, not legal advice; if you redistribute Sqitch inside a product, have your own counsel read the notice requirement.

On maintenance, the repository is not archived and the last push was on 2026-09-14, which is recent. Releases are infrequent and deliberate: v1.6.0 on 2025-10-06, v1.6.1 on 2026-01-06, with v1.5.2 before that in April 2025. The README header shows the development version as v1.6.2-dev, so work continues on the develop branch between tagged releases.

The upgrade cost sits in the Perl dependency tree rather than the plan file. A distribution install runs ./Build installdeps, and a bundle install pins the driver set at build time. If you deploy from a bundle, adding an engine later means rebuilding the bundle with another --with flag, not installing a plugin. Plan for that in your image build rather than discovering it during an incident.

Editorial conclusion

Adopt Sqitch if your team already writes SQL by hand and wants the ordering, rework and verification handled by a tool that does not care which framework sits on top of the database. Do not adopt it if you expect the migration tool to generate schema diffs from your model classes, or if you cannot commit to maintaining a plan file alongside the scripts. Before deploying, verify that the engine you use appears in the supported list with a matching version, and run sqitch verify against a copy of the target database, because the plan file records intent while only the database records what actually ran.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sqitchers/sqitch on GitHub