Top Open Source Postgres Migration Tools in 2026

PostgreSQL keeps topping the popularity charts (DB-Engines named it DBMS of the Year in 2023, runner-up in 2024). And yet doing a schema migration in Postgres is still a PITA. A small industry of tools has grown up to make it less so, and they don't all solve the same problem. The ones that apply your SQL fall into three camps: the versioned-migration tools that run your scripts in order, the declarative tools that diff a desired schema against the live one, and the zero-downtime specialists that rewrite big tables without taking a lock. Bytebase is the odd one out: it can run the migration too, but what it adds is the governance layer around the change.

Here's the full list, all open source and, with the one exception I flag under Reshape, actively maintained as of September 2026:

• Flyway
• Liquibase
• Sqitch
• graphile-migrate
• DBLift
• Atlas
• pgschema
• pgroll
• Reshape
• Bytebase

The versioned camp#

Flyway#

Flyway is the one your CI probably already runs. You write each change as a numbered SQL file (V1__init.sql, V2__add_index.sql), Flyway applies them in order, and it records what ran in a flyway_schema_history table. It's Java, and ships as a CLI, a library, Maven and Gradle plugins, and a Docker image.

Redgate bought Flyway in 2019 and, to their credit, kept the developer-first feel while stacking paid tiers on top (Enterprise adds undo, dry runs, and drift checks). The open source Community edition still covers the core job. It's on the 13.x line now. ~10,100 stars.

The honest limitation: Flyway runs migrations, full stop. Review, approval, and audit are yours to solve elsewhere. More in Bytebase vs. Flyway.

Liquibase#

Liquibase is the enterprise incumbent. Changes live as a changeset inside a changelog, and because of its Java roots the canonical format is XML (YAML, JSON, and plain SQL came later).

Liquibase 5.0 shipped in early 2026, folding the old Pro capabilities and a reworked flow engine into the main line. The core stays free; Pro and Secure tiers add policy checks and reporting. ~5,600 stars.

To be honest, the XML is the part I'd push back on. It takes a paragraph of markup to add one column. If your shop already standardized on Liquibase changelogs, it's a fine default and the integrations are unmatched. If you're starting fresh, that verbosity is a tax you're choosing to pay. More in Bytebase vs. Liquibase.

Sqitch#

Sqitch is for people who just want SQL and nothing else. No version numbers, no framework. You write three scripts per change (deploy, revert, verify), and Sqitch tracks dependencies between changes instead of a linear counter. Perl, MIT-licensed, no paid tier. ~3,200 stars.

The dependency model is the clever bit. Declare that change B depends on A, and Sqitch refuses to deploy B first. It rides directly on psql, so there's almost nothing to learn if you already write SQL by hand. FWIW, this is what I'd reach for when a project wants reversible plain-SQL migrations without a heavyweight.

graphile-migrate#

graphile-migrate is the framework-native member of the versioned camp: opinionated, roll-forward, and written in TypeScript for the Graphile and PostGraphile crowd. Its signature is a git-like local loop: graphile-migrate commit moves the current migration into the committed/ folder and resets a shadow database, and uncommit backs it out while you iterate. ~840 stars.

If you're not already in PostGraphile land, there's little reason to reach for it. If you are, it fits like a native.

DBLift#

DBLift is the only Python tool on this list, built for one annoyance: a Python team keeping a JVM patched just so Flyway can apply SQL files. DBLift reads the same V1__init.sql naming convention, installs with pip, and runs as a CLI or as a library inside your app or your pytest suite. dblift import-flyway copies an existing flyway_schema_history, so switching doesn't reset anyone's history.

Undo scripts and a dry run that prints the exact SQL ship in the Apache-2.0 package. Flyway keeps both in its paid edition. A Pro tier adds SQL linting and drift detection. One default to know before you migrate: DBLift applies out-of-order migrations unless you pass --strict, the opposite of Flyway.

Where it stands: the repo went public in June 2026 and has a handful of stars, against Flyway's decade of production mileage. Alternatives: Alembic, if your schema is driven by SQLAlchemy models and you want autogenerated revisions instead of hand-written SQL.

The declarative camp#

Atlas#

Atlas brings the Terraform model to database schema. You declare the schema you want (in HCL, SQL, or straight from an ORM), Atlas plans the diff against the live database, then applies it. It also does versioned migrations, so you can work declaratively and still generate files for review. Go, from the Ariga team.

The core is Apache-2.0. Atlas Pro, sold through Atlas Cloud, adds linting, drift detection, and a schema registry. ~8,700 stars and moving fast. If you love terraform plan, you'll feel at home immediately. One thing to weigh: its diffing overlaps with the dedicated Postgres schema compare tools, so decide up front whether you want one tool doing both jobs.

pgschema#

pgschema (Go) does the same declarative, Terraform-like flow, but Postgres-only:

• Dump a Postgres schema in a developer-friendly format
• Edit it to the desired state
• Plan the change by diffing desired against current
• Apply with concurrent-change detection, transaction-adaptive execution, and lock-timeout control

Postgres-only is the feature. Instead of the lowest-common-denominator abstraction a multi-engine tool settles for, it diffs 16 kinds of schema object across Postgres 14 through 18, including the ones generic tools tend to skip: row-level security policies, partitioned tables, constraint triggers, domains, default privileges, and column-level grants. It launched in mid-2025 and is already past 1,000 stars and on the 1.x line.

The zero-downtime specialists#

pgroll#

pgroll (Go, from Xata) tackles the genuinely hard one: schema change with zero downtime. It uses the expand/contract pattern, keeping both the old and new schema valid behind versioned views so the old and new versions of your app run side by side during a rollout.

Apache-2.0, actively developed, ~6,600 stars. This is the tool you add the day a plain ALTER TABLE on a hot 40-million-row table would lock writes long enough to page someone. You don't need it until you very much do.

Reshape#

Reshape got there first with the same view-based, zero-downtime idea, written in Rust. A migration runs in three phases: start sets up the views and triggers so both schemas work, you roll out the app gradually, and complete drops the old schema.

The caveat: the author has moved on to ReshapeDB, a database built from the ground up around zero-downtime migrations, and Reshape itself (~1,900 stars) now sees less activity than pgroll. It's worth reading to understand expand/contract. But if you're choosing today, pgroll is the more actively maintained take on the same trick.

The governance layer#

Bytebase#

Full disclosure: Bytebase is ours, so read this with the appropriate grain of salt. Everything above applies SQL. Bytebase governs the change around it. Think GitHub or GitLab for database changes, where developers and DBAs collaborate through a GUI or a GitOps workflow. Go and TypeScript, ~14,500 stars.

It runs configurable SQL review rules to catch anti-patterns, a missing NOT NULL or a dangerous DDL statement, before a change reaches production.

It also keeps change history, approval flows, and an audit log, plus a SQL Editor with data access control and dynamic data masking on the query path.

Bytebase can be the whole pipeline, from the SQL a developer submits to the rollout across environments, or it can work next to the migration tool your CI already runs. If your problem isn't running the SQL but knowing who approved a change and whether what ran matched what was approved, that's the gap it fills. See how to build a CI/CD pipeline for database schema migration and database version control.

Summary#

My take#

So which one? If I'm starting a new Postgres project today, I'd use Sqitch or Flyway for everyday versioned migrations. If your team thinks in desired state, pgschema is my pick for a Postgres-only shop, and Atlas if you need the same model across several engines.

And once more than a couple of people are touching production, the bottleneck stops being which tool applies the SQL. It becomes who's allowed to run a change, who approved it, and what actually ran. That's the unglamorous part, and none of the tools above do it. They shouldn't. Applying SQL is a different job.

It matters more now that AI agents write migrations too. An agent can produce a plausible ALTER TABLE in seconds, and it will never be the one paged when that statement locks a hot table. So it needs what any engineer needs: its own identity instead of a shared credential, a review gate before production, and an audit trail afterwards. That governance layer is what we built Bytebase to provide, for people and agents alike.