
Moksh GuptaPick a migration tool and you are picking two things at once: a file format for schema changes, and a...
Pick a migration tool and you are picking two things at once: a file format for schema changes, and a license you will still be living with in three years. Most comparisons only cover the first one.
That second half moved in 2026. I dug into the licensing and the drift-detection story in a longer writeup on DevToolLab; this is the condensed version with the parts that actually change a decision.
Liquibase Community 5.0 shipped on September 30, 2025 under the Functional Source License 1.1, not Apache 2.0. FSL is source-available: you can run it in production for free and fork it, but each release stays restricted for two years before converting to Apache 2.0.
The knock-on effects were immediate. Keycloak opened an issue tagged priority/blocker on October 13, 2025, noting that "CNCF does not permit source available licenses", and listing its options as swapping the component, freezing at the last Apache-licensed release, or forking. As of September 14, 2026 that issue is still open.
If your organization has a license policy, or you redistribute the tool inside a product, this settles the comparison before you get to features.
Most teams run one database engine, not five. The 2025 Stack Overflow Developer Survey put PostgreSQL at 58.2 percent of professional developers, MySQL at 39.6 percent and Microsoft SQL Server at 30.9 percent. Multi-engine support is the headline feature of the enterprise tools and the one most teams will never touch.
Raw usage splits along a different line. Package volume follows the ORMs: in the week of September 5 to 11, 2026, npm served 13,644,360 downloads of drizzle-kit and 12,653,834 of prisma, against 3,843,592 for knex. Mindshare follows the standalone CLIs, and GitHub stars on September 14, 2026 put golang-migrate at 18,919, Bytebase at 14,483, Flyway at 10,085, Atlas at 8,724, Liquibase at 5,611 and Alembic at 4,389. The two vendors with the biggest sales teams sit in the middle of that list.
Here is the failure mode that decides more than any feature matrix. Versioned tools such as Flyway, Liquibase and Alembic track an ordered list of scripts plus a table recording which ones ran. Declarative tools such as Atlas keep a description of the schema you want and diff it against the live database every run.
The consequence: a versioned tool is structurally blind to any change that did not arrive through it. Apply two migrations, then have someone run an ALTER TABLE by hand at 2am, and ask both models what they see:
versioned check - what the history table knows
V1__init applied
V2__add_orders applied
status: up to date, 2 of 2 applied
declarative check - desired state vs live database
orders: column "discount_cents INTEGER" exists in the database but not in the migrations
status: 1 drift found
Both ran against the same database. The history table reports a clean bill of health because every file it knows about succeeded, which is the only question it was ever designed to answer. The original post has the full dependency-free Node script that produces this, using node:sqlite, if you want to run it against your own staging schema.
Drift detection is the single feature worth paying for in this category, and that is exactly why it sits behind the paid tier almost everywhere.
Flyway is what most teams mean by "just run the migrations": a Java CLI that executes numbered SQL files and logs them in flyway_schema_history. Plain SQL, no DSL, nothing to fight when you need an engine-specific feature. Drift detection and undo generation are Enterprise features, and the Teams tier carries a documented 100-schema cap. Redgate now positions Community as being for individuals and education, though the code on GitHub is still Apache 2.0. Version 13.6.0 landed September 10, 2026.
Liquibase bets the other way: describe changes in a changelog (XML, YAML, JSON or SQL) and let it emit engine-specific statements. The support matrix is the widest here at 65 or more databases, and rollback is a first-class concept rather than an upsell. Version 5.0.4 shipped August 20, 2026 under FSL-1.1-ALv2.
Atlas is the declarative option: write the schema you want, and it plans the migration by diffing against the live database.
That makes drift checking a normal part of the workflow instead of a paid feature, and its linter fails a migration that would lock a large table in CI rather than in production. The cost is that you give up hand-written migration files as the source of truth. Apache 2.0, version 1.3.0 from August 2, 2026, Pro from $9 per developer per month.
Bytebase is not really a migration engine. It is the review queue, approval workflow and audit trail you wrap around one.
If your last outage happened because somebody ran SQL straight against production, this is the category that fixes it. The core is MIT, but anything under an enterprise directory is separately licensed, and the free tier stops at 20 users. Version 3.22.1, September 10, 2026.
Prisma Migrate ships inside the ORM: edit schema.prisma, run prisma migrate dev, get an editable SQL file generated by diffing model against database. It also refuses destructive migrations without explicit acknowledgment. One caveat worth knowing right now: ORM 8 is a release candidate with general availability expected October 2026, and $extends, most nested writes and the familiar P2002 error codes are not in it yet. Pin to the 7 line (7.10.0, August 25, 2026).
Alembic is what Python teams already have, written by the author of SQLAlchemy. Autogenerate drafts a revision by comparing your models to the database, and because the output is a Python file you can add backfills and batch operations in the same revision. The docs are direct that autogenerate misses some changes, renames among them, so a generated revision is a first draft. MIT, version 1.20.0, September 11, 2026.
| Tool | Model | Entry price | Drift detection | License |
|---|---|---|---|---|
| Flyway | Versioned SQL | Free Community | Enterprise only | Apache 2.0 |
| Liquibase | Versioned changelog | Free Community | Paid tier | FSL-1.1-ALv2 |
| Atlas | Declarative | $9/dev/month | Built in | Apache 2.0 |
| Bytebase | Governance platform | $20/user/month | Built in | MIT core |
| Prisma Migrate | ORM-integrated | Free | No | Apache 2.0 |
| Alembic | ORM-integrated | Free | No | MIT |
Count your engines before buying for many. If the honest answer is one, Liquibase's abstraction is cost you are carrying for nothing.
Run a drift check against a real staging database before anything else. Find nothing and versioned migrations are enough for now. Find something and you have a governance problem that no migration tool fixes on its own.
Check the license policy before the feature list, because for a lot of teams it removes an option outright. Then ask who is allowed to touch production: if several people can do it directly, an approval queue matters more than the file format. And test the rollback before you need it, since undo is paid in Flyway and free in Liquibase and Alembic, and that gap only surfaces under pressure.
Single Postgres or MySQL database on a small team: Flyway Community. Plain SQL, Apache 2.0, nothing to operate. Add a nightly drift check in CI and you have covered most of what the paid tier sells.
Already on Prisma or SQLAlchemy: use the migrator you already have and stop shopping. A second tool alongside your ORM means two sources of truth for one schema.
Schema changes cause your incidents: Atlas. Declarative diffing plus linting catches the locking and destructive changes before production.
Auditors and several engines: Liquibase Secure if your policy permits FSL, Bytebase if it does not.
What changed in this category during 2026 was not a feature, it was a license. Liquibase leaving Apache 2.0 removed the obvious open-source answer for multi-engine migrations, and what remains is either single-purpose CLIs such as golang-migrate and goose, or declarative tools like Atlas that ask you to change how you work.
Before you renew anything here, ask one question: if somebody alters production by hand tonight, which of these tells you tomorrow morning? Run it against your own setup and most free tiers come up empty.
Two things that help while you are writing the migrations themselves: the SQL Formatter normalizes statements so a code review shows the schema change rather than somebody's indentation, and the SQL Create Table Generator drafts the DDL for a first migration from column definitions.