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, and the multi-environment comparison in October 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 |
| Promote one change from dev to prod and across hundreds of tenant databases, with a gate per environment | Bytebase; Octopus Deploy or Harness if one already runs your releases |
| 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 synchronization across databases
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.
Multi-environment and batch database deployments
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 to every production database (one per tenant, sometimes hundreds of them, spread across regions), in the right order, with a gate between stages and a record afterwards, is not.
There are two dimensions here, and tools handle them differently:
- The environment pipeline: dev → test → staging → prod. The same change has to be promoted in order, and production should only see what has already run upstream.
- The fan-out inside an environment: production is often not one database but one per tenant, region or shard. The change has to reach all of them, and someone has to decide what happens when database 37 of 400 fails.
A multi-environment rollout needs six things: per-environment targeting, promotion order, a gate before the sensitive stages, a failure policy for the fan-out, a record of what ran where, and a way to catch environments that have drifted apart.
How each tool handles it
| Tool | How environments are modelled | Promotion order and gates | Fan-out across many databases | Drift between environments |
|---|---|---|---|---|
| Flyway | [environments.<id>] tables in flyway.toml, picked with -environment=prod | Your CI pipeline | A loop in your CI pipeline | Drift detection in Enterprise |
| Liquibase | One changelog; contexts filter which changesets run where (--contexts=prod), labels filter by release | Your CI pipeline; Flow files (Secure) chain steps | A loop in your CI pipeline | Drift report from diff (Secure) |
| Atlas | env blocks in atlas.hcl, picked with --env prod | Order in your CI pipeline; each apply can wait on a review policy or an approved plan | for_each expands one env into a target per tenant; the deployment block (Pro) adds canary groups, parallel, and an on_error policy (FAIL or CONTINUE) | Drift detection in Pro |
| Octopus Deploy | Environments, promoted through a Lifecycle | Lifecycle phases, each environment automatic or manual | Tenants, each tracked on its own path through the lifecycle | Whatever the migration tool it runs provides |
| Harness Database DevOps | Environments defined in the pipeline; each database instance carries a context | Pipeline stages; a Preview SQL → Manual Approval → DB Schema Apply pattern per stage | Pipeline stages per instance | Whatever the migration tool it runs provides |
| DBmaestro | Environments in a release pipeline | Role-based approvals before each promotion | Releases packaged once and promoted across environments | Scans environments against a baseline (vendor-described) |
| Bytebase | Workspace environments in an order you set; every database belongs to one | A Plan's targets become Rollout stages in environment order; per-environment rollout policy (automatic or manual, environment-specific releaser roles); approval and plan checks required first by default | Database groups (Pro) select tenants by label; each database is its own task with its own run history | No automatic drift detection; check on demand through the API (sync the live schema, diff it against the last changelog), and Schema Synchronization generates the DDL to align a drifted database |
The CLI rows look similar for a reason. Flyway, Liquibase and Atlas model environments as connection profiles: they make it easy to point the same migrations at a different database, but deciding when prod goes, who said yes, and what to do when one target fails is left to the pipeline that calls them. Atlas goes furthest, with tenant fan-out, a staged rollout strategy and per-apply approval built in, but the order from staging to prod still lives in CI.
The orchestration rows model environments as stages with state. Octopus and Harness already do this for application releases, so a database step inherits the same lifecycle and approval gates — which is why it's the pragmatic choice if one of them already runs your deploys. Bytebase does it on the database side. For a batch change, a database group selects every tenant database by label, and one change becomes one rollout: a stage per environment in workspace order, a gate and a releaser set per environment, and a task per database whose run history is the record of what ran where.
Questions to ask before you pick
- Where does promotion order live? In a tool's configuration, or in pipeline YAML that one person wrote two years ago?
- Is the production gate enforced or conventional? A manual step in CI can usually be skipped by anyone who can edit the pipeline.
- What happens when one target fails mid-fan-out? Stop everything, continue and report, or nobody knows until it happens.
- Can you answer "which tenants are on this change?" without querying each database's history table by hand?
- Does drift between environments surface on its own? A hotfix applied straight to prod is the usual reason staging stops predicting production. Check the edition, too: in most of these tools drift detection is a paid feature.
If your answers all point at CI configuration nobody really owns, a CLI is no longer the bottleneck, the coordination is. Orchestrators solve the sequencing. Governance platforms solve the sequencing plus the approvals and the record. 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.