This post is maintained by Bytebase, an open-source database governance platform. We update the post periodically.
Writing a database change is the easy part. Getting it deployed is where things tend to go wrong.
A missing migration, a bit of schema drift, or a change applied to the wrong environment can break production quickly, and often quietly. Nobody notices until users complain or the dashboards go red.
DevOps teams lean on a small set of tools to deploy database changes. On the surface a lot of these tools look alike. In practice they solve quite different problems.
This post walks through the database deployment tools teams reach for in 2026, and how they differ in the way changes are defined, applied, and coordinated. Every licence, edition and price below was verified in August 2026.
If you just want the shortlist:
| What you're trying to do | Reach for |
|---|---|
| Version schema changes as SQL files and let CI apply them in order | Flyway |
| The same, in an org standardized on changelogs, or on Oracle and Db2 | Liquibase |
| Declare the schema you want and have the tool plan the diff | Atlas, or pgschema if you're Postgres-only |
| Run database steps inside your existing release pipeline | Octopus Deploy, Harness Database DevOps |
| Require review before production, and prove afterwards what ran where | Bytebase, DBmaestro |
What we mean by "Database Deployment Tools"
Before listing anything, it's worth being clear about scope.
This post is about general-purpose database deployment tools: tools built to manage and deploy database schema changes directly.
We're leaving out a few categories on purpose:
- ORM-driven tools where the database schema is derived from application models (for example, Prisma Migrate or Drizzle)
- CI/CD systems and infrastructure tools (GitHub Actions, GitLab CI, Terraform)
- Framework-specific migration systems (Rails or Django migrations)
Plenty of these can run SQL. That on its own doesn't make them database deployment tools in the sense we're discussing.
A simpler way to understand the landscape
Most of the confusion around database deployment tools comes from mixing different concerns together.
There are really three separate questions:
- How are database changes defined? As migrations, or as a desired schema state?
- How are those changes executed? Almost always via a CLI.
- How are deployments coordinated across teams and environments? Reviews, approvals, rollout, audit, and visibility.
Once you pull these apart, the tooling gets a lot easier to reason about. The first two questions belong to the CLI tools. The third belongs to a different layer entirely, and the vendors themselves agree: Harness describes its own database module as "a pipeline-native orchestration layer built on top of migration tools like Liquibase and Flyway — not a replacement for them." Layers, not rivals.
CLI-based database deployment tools
Most database deployment tools today are CLI-based.
You run a command locally or in CI, the tool connects to a database, and it applies the changes. What sets these tools apart isn't how they execute, it's how database changes are defined in the first place.
Migration-based tools (CLI)
Migration-based tools deploy database changes as explicit migration scripts, usually written in SQL.
Each migration is a small, incremental change. The tool keeps track of what has already run and applies the rest in order. Explicit files, predictable execution, a familiar mental model, easy to adopt.
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 records what ran in a flyway_schema_history table. Broad database support, easy CI integration, ships as a CLI, a library, build plugins, and a Docker image.
Redgate acquired Flyway in 2019 and kept the developer-first feel while stacking paid tiers on top. The Community edition is Apache 2.0 and still covers the core job. Redgate's product pages now front just two editions, Community (free) and Enterprise (quote only) — Teams, the old middle tier, is no longer presented as a buying option. Enterprise is where undo migrations, dry runs, drift detection and the newer agentic features live: the Flyway MCP Server, which routes AI-proposed schema changes through the same policy checks as human-written ones, is Enterprise-only. ~9,970 stars, on the 13.x line as of July 2026.
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; the canonical format is XML, with YAML, JSON and plain SQL added later. Its database coverage is the widest here, which is why it survives in Oracle and Db2 estates where nothing else has drivers.
The licence is the thing to know this year. Liquibase 5.0 shipped on 30 September 2025, and with it Liquibase Community moved off Apache 2.0 to the Functional Source License. You can still use it freely in production, modify it and contribute, but the FSL blocks competing commercialization, and each version's code only reverts to Apache 2.0 two years after its release. If you embed Liquibase in something you sell, read the licence before you upgrade; if you just run it, nothing changes. The commercial line is now branded Liquibase Secure, in four quote-only tiers, and the lower two are restricted to companies under $1B in annual revenue. ~5,570 stars, currently 5.0.3.
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 it, it's a fine default and the integrations are unmatched. See Flyway vs. Liquibase for the direct comparison.
Also worth knowing
- goose (Go, ~11,300 stars) — plain SQL with explicit up/down sections, plus Go migrations when a change needs logic. A single binary with no runtime to install, which is why it's the default in a lot of Go services.
- Sqitch (Perl, MIT, ~3,150 stars) — still migration-based, but orders changes by dependencies instead of linear version numbers and pairs every change with a verify script. Suits complex or parallel database development where a strict numeric sequence causes constant rebasing.
Where migration-based tools work well: application-driven schema changes, incremental evolution, teams comfortable owning SQL migrations.
Where they fall short: cross-team coordination, visibility across environments, approval, audit, and change control. At scale, migrations tend to become "just another pipeline step," even though their blast radius is much larger than application code.
Declarative / state-based tools (CLI)
Declarative tools take a different route.
Instead of writing step-by-step migrations, you define what the schema should look like, and the tool works out how to get there. Execution still happens through a CLI.
Atlas
Atlas (Go) compares the desired schema state with the actual database schema, generates the diff, and applies the required SQL. You can declare the state in HCL, plain SQL, or by pointing Atlas at your ORM models, and it layers migration linting and CI checks on top.
The licensing is easy to get wrong, so it's worth spelling out: the default Atlas binary ships under the Atlas EULA, not an open source licence. The Apache 2.0 Community Edition is a separate, minimal build that omits many drivers, commands and integrations. So "Atlas is open source" is true of a narrower thing than most roundups imply. Pricing: Starter is free; Pro is $9 per developer per month plus usage-based CI/CD pricing; Enterprise is custom. ~8,630 stars.
pgschema
pgschema (Go, Apache 2.0, no feature gating) runs the same Terraform-style flow — dump, edit, plan, apply — but Postgres only, with no migration table or shadow database required. Postgres-only is the point: it tracks the objects generic tools skip, like row-level security policies, partitioned tables, partial indexes and column-level grants. It's young (~990 stars), so I'd trial it on a side project before betting a production pipeline on it. Disclosure: pgschema is part of the pgplex toolchain, which Bytebase sponsors.
Where this works well: teams comfortable with declarative workflows, tightly controlled environments, enforcing schema consistency.
Tradeoffs: less explicit control over each change, you have to trust the generated diff, and it's riskier for large, long-lived production databases.
Migration-based and declarative tools disagree on how changes are defined, but they share the same execution model: a CLI applying changes directly to the database.
Database deployment orchestration and control
CLI tools are good at one thing: applying changes.
They don't answer questions like:
- Who is allowed to deploy this?
- Has this change been reviewed?
- Which environments are affected?
- What happened after deployment?
- How do multiple teams avoid stepping on each other?
That's the gap orchestration tools fill, and Bytebase isn't the only occupant of this layer. Octopus Deploy and Harness Database DevOps slot the database step into an existing application release pipeline — both call migration tools like Flyway and Liquibase underneath rather than replacing them — and DBmaestro plays the same role for regulated enterprise estates. If one of these already runs your application deployments, evaluating its database module first is the pragmatic move.
Bytebase takes the governance angle, and it's the one I work on, so read this knowing that. It is SQL-first and doesn't introduce a proprietary DSL. Database changes are written in native SQL, the same as with migration tools.
In practice:
- Migration-based workflows are the primary model
- Declarative capabilities are also available for schema comparison and drift detection
What makes Bytebase different isn't how the SQL is written, it's how deployments get coordinated.
Bytebase gives you multiple ways to deploy the same SQL:
- A GUI for review, approval, and visibility
- An API for automation and internal platform integration
- A GitOps workflow for pull-request-driven deployments
Around that sit the controls: custom approval flows, SQL review rules enforced before a change runs, staged rollout across environments, and an audit trail of what ran where and who signed off. Rather than replacing CLI tools, Bytebase sits on top of them as a control plane, handling policy, approval, rollout, and audit across environments.
Pricing: Community is free forever (up to 20 users, 10 database instances); Pro is $20 per user per month; Enterprise is custom. ~14,350 stars, MIT Expat apart from the enterprise directories.
Honest limitation: if you only need to apply migrations from CI and nobody is asking who approved what, this is more machinery than you need — Flyway is the lighter answer.
The multi-environment problem
One thing worth separating out, because it's the reason teams outgrow a CLI more often than any single missing feature.
Applying a change to one database is a solved problem. Applying the same change to dev, then staging, then twelve production databases across three regions, in the right order, with a gate between stages and a record afterwards, is not. A migration CLI models a single target, so the rollout ends up expressed in pipeline YAML — and the ordering, the halt-on-failure behavior and the audit trail quietly become CI configuration nobody really owns.
Orchestrators solve the sequencing. Governance platforms solve the sequencing plus the approvals and the record. If that's the shape of your pain, database multi-environment deployments goes into the patterns in more depth.
Putting it together
Seen clearly, the landscape is smaller than it first looks:
- CLI-based tools define and apply database changes
- Migration-based: Flyway, Liquibase, goose, Sqitch
- Declarative: Atlas, pgschema
- Orchestration and control tools manage how those changes move through environments
- Release orchestrators: Octopus Deploy, Harness Database DevOps, DBmaestro
- Governance control plane: Bytebase
A note on "open source" while you're shortlisting, since it turned out to be the least stable fact in this landscape: goose, Sqitch and pgschema are fully open source; Flyway Community is Apache 2.0; Liquibase Community is FSL since September 2025; and Atlas's open source licence covers a reduced Community build, not the default binary. Check the licence, not the label.
There's no single "best" database deployment tool. A small team may be perfectly happy with a simple migration tool. As systems grow, coordination and visibility start to matter as much as execution — what changes is not the volume of SQL but the number of people and environments touching it.
Database deployment was never really about running SQL.
It's about keeping changes predictable, visible, and safe as teams and systems scale.
Once you separate (1) how changes are defined, (2) how they're executed, and (3) how they're coordinated, picking the right tools gets a lot easier.