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. Over the years a small industry of tools has grown up to make it less so, and they don't all solve the same problem. Put simply, the tools that apply your SQL fall into three camps: the versioned-migration veterans that run your scripts in order, the declarative newcomers 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, a governance layer that sits on top of whichever camp you pick. I'll get to why.

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

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

The versioned veterans#

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 (Teams and Enterprise add undo, dry runs, and drift checks). The open source Community edition still covers the core job. It's on the 12.x line now, with 12.9 shipping in June 2026. ~9,900 stars.

The honest limitation: Flyway runs migrations, full stop. Review, approval, and audit are your problem to solve elsewhere. I go into that boundary 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 is 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 on where it fits 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,100 stars.

The dependency model is the clever bit. Declare that change B depends on A, and Sqitch refuses to deploy B first. It fits Postgres like a glove and 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 dragging in 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.

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,600 stars and moving fast. If you love terraform plan, you'll feel at home immediately. One thing to weigh: its declarative diffing overlaps with the dedicated Postgres schema compare tools, so decide up front whether you want one tool doing both jobs.

pgschema#

pgschema is the new kid (Go), doing 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 a feature here, not a limitation. It can lean on Postgres specifics instead of the lowest-common-denominator abstraction a multi-engine tool has to settle for. It's early though (~970 stars), so I'd trial it on a side project before betting a production pipeline on it. Alternatives: Atlas, if you want the same model with more mileage and multi-engine support.

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,500 stars. Put simply, 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.

Here's the caveat I'd want to know before adopting it. The author has moved on to ReshapeDB, a database built from the ground up around zero-downtime migrations, and Reshape itself (~1,800 stars) now sees less activity than pgroll. It's a great idea and 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. It's the odd one out on this list, on purpose. 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,000 stars.

It runs configurable SQL review rules to catch anti-patterns, a missing NOT NULL or a dangerous DDL, 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.

To be clear, Bytebase doesn't replace Flyway or pgroll at the apply step. It wraps review, approval, and audit around whatever migration style you already use. If your problem isn't running the SQL but knowing who approved a change and whether what actually 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 and keep pgroll in my back pocket for the handful of changes that would otherwise lock a big table. If your team thinks in desired state, Atlas is the safer bet than the newer pgschema, at least for now.

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, and what actually ran. That's the boring, unglamorous part, and it's exactly where most migration outages come from. Pick the migration tool you like. Just don't skip that part.