Executive Summary
Ask every vendor two questions first: how a change is undone after it has run, and what record an auditor receives of who approved it.
Database DevOps tools put schema and data changes through the same version control, review and deployment pipeline as application code. They record which changes have run on each database, check a change before it runs, and keep a history of who approved it. An article on Martin Fowler's site states that database migration frameworks typically create a changelog table and automatically update it whenever a migration is applied, so the database can always report which migration it is synchronized with.
Choose a tool on five things: how a change is written (a script for each step, or the desired end state of the schema); how a change is undone after it has run; what approvals and audit records it keeps for compliance; which databases and pipelines it supports; and what its price meter counts as adoption grows.
The vendors divide by the product they started from: migration engines that run versioned scripts, a state-based toolchain for one database family, release automation built around governance, a web console for change and access, schema-as-code tooling, a database stage inside a CI/CD platform, and a managed database that runs its own schema changes. No tool here reverses every change. Rehearse the way back on a copy of your own data before you sign.
What Makes Database DevOps Compliant?
Auditors ask the same questions of a database change as of any production change: who requested it, who approved it, what ran, and whether anyone could have gone around the process. NIST SP 800-128 states that the goal of security-focused configuration management (SecCM) activities is to manage and monitor the configurations of information systems to achieve adequate security and minimize organizational risk while supporting the desired business functionality and services. A database schema is part of that configuration. A script run by hand from a laptop leaves no record that answers those questions.
Separation of duties keeps the author of a change from approving and deploying it alone. NIST states that separation of duties can be enforced either statically, by defining conflicting roles that cannot be executed by the same user, or dynamically, by enforcing the control at access time, and that an example of dynamic separation of duty is the two-person rule. In a database DevOps tool, the two-person rule is an approval step that the author of the change cannot complete.
Approval workflows differ in what they cover. Bytebase states that Custom Approval enables organizations to implement approval workflows for database operations including schema and data changes, database creation, role requests, and access grant requests. PlanetScale states that, to ensure only approved schema changes are applied to production, an approval is automatically dismissed if the proposed changes are updated after the deploy request is approved. Harness states that it enforces database change rules automatically, routes high-risk operations to the right approvers, and maintains full audit trails. Ask whether an approval is tied to the exact script that will run, and what happens to it when the script changes.
Audit records differ in scope, and in the plan that includes them. DBmaestro states that every change is recorded automatically, including who changed what, when, from which instance and under which approval, and that the evidence can be filtered, reviewed and exported for SOX, HIPAA and GDPR. Bytebase states that audit logging tracks all configuration changes and data operations within a Bytebase workspace, including who performed what action, when it occurred, and what resources were affected. Bytebase states that audit logging is available only for Pro and Enterprise plans. Confirm that the plan in your quote includes every feature your auditors will rely on.
Role rules decide who may run which kind of change. DBmaestro states that it lets you define who can make which types of changes, and enforces the roles, responsibilities, and policies behind them automatically. Liquibase describes automating policy enforcement, managing exceptions without bypassing controls, and giving teams autonomy while maintaining security and separation of duties. Ask how an exception to a policy is requested and approved, and whether the exception appears in the audit record.
How Do Database DevOps Tools Roll Back a Change?
In four ways, and most tools support one or two: a reverse script written or generated for each change, a plan computed from the current state of the database, a copy of the rows a change touched, and a revert window kept by the database service. A reverse script can recreate a dropped column. It cannot bring back the values that were in it unless a copy was kept first.
A reverse script is written or generated for each change. DBmaestro states that it handles database rollbacks by automatically generating and validating downgrade scripts alongside deployment packages. Redgate states that undo migrations form one possible rollback strategy with some limitations in practice, and that they work for undoing schema changes but not so well for undoing data changes. The two main migration engines write reverse scripts differently, as the next section shows.
The alternative to undoing a change is to make every change safe to leave in place. Redgate suggests maintaining backwards compatibility between the database and all versions of the code currently deployed in production, so that the application code can be rolled back while the database stays compatible with the old version. Martin Fowler's site describes parallel change, also known as expand and contract, as a pattern to implement backward-incompatible changes to an interface in a safe manner, by breaking the change into three distinct phases: expand, migrate, and contract. Martin Fowler's site states that most database refactorings follow the parallel change pattern, where the migrate phase is the transition period between the original and the new schema, until all database access code has been updated to work with the new schema. With expand and contract, a failed release rolls back the application, and the database keeps both shapes until the contract step.
Some tools compute the way back instead of storing it. Atlas states that its migrate down command reverts applied migrations by computing a migration plan based on the current state of the database, instead of running pre-planned down files. Atlas states that by default it generates and executes a set of pre-migration checks to ensure the computed plan does not introduce destructive changes or delete data. Others copy the data a change will alter. Bytebase states that its Prior Backup captures a snapshot of data before changes are applied, storing the original state of affected rows so that data changes can be reverted with 1-Click. Bytebase states that prior backup is feasible when all of these conditions are met: an UPDATE or DELETE statement, no mixed UPDATE and DELETE on the same table, a SQL statement size less than 2M, and no mixed DDL/DML.
A managed database can run the change and keep the old schema for a while. PlanetScale states that database branching, coupled with deploy requests, allows you to deploy non-blocking schema changes to a production database with zero downtime, and to undo deployments without losing any data written during that time. PlanetScale states that a deployment can be reverted for up to 30 minutes, after which it becomes permanent. PlanetScale states that deploy requests that are instantly deployed cannot be reverted. A delivery platform can also run the rollback as a pipeline step. Harness states that rollback in Harness Database DevOps can revert to a Liquibase tag, by count, a specific changeset, or Flyway migrations to a specific target version.
Write the rollback plan before the change is approved. For each change, record the method that applies, whether it restores data or only structure, and how long the option stays open.
| Method | How it works | What it does not undo | Ask the vendor |
|---|---|---|---|
| Reverse script, hand-written | A developer writes the undo for each change, run in reverse order | Data removed by the forward change | Which change types require a hand-written script |
| Reverse script, generated | The tool writes the undo from a modeled change | Change types the tool cannot model | Which change types and formats it generates for |
| Computed down plan | The tool compares the database with the target version and plans the difference | Values in objects the forward change dropped | Which checks run before the plan is applied |
| Row copy before the change | Rows an UPDATE or DELETE will touch are copied first | Schema changes, and statements outside the supported cases | Where the copy is stored, and for how long |
| Revert window | The database service can switch back to the previous schema for a set time | Anything after the window closes | How long the window lasts, and which deployments it excludes |
| Expand and contract | Each step stays compatible with the running code, so the application rolls back instead | Nothing, while every step stays compatible | Whether the tool flags backward-incompatible changes |
Migration Scripts or Desired State: Comparing the Change Models
In a migration-based tool, a developer writes an ordered script for each change, and the tool records which scripts have run on each database. In a state-based tool, the developer edits the desired schema, and the tool computes the script by comparing that schema with the target database. Migration scripts show a reviewer exactly what will run. A desired state is shorter to review but needs extra scripts wherever data has to move. An article on Martin Fowler's site states that the usual rule is to make each database change as small as possible, because the smaller it is, the easier it is to get right, and any errors are quick to spot and debug.
The two migration engines in this guide differ in format, in how undo is written, and in license terms. Format: Redgate states that every Flyway migration is written in the native language of the target database, plain SQL for relational databases. Liquibase states that for modeled changelogs (XML, YAML, JSON) it automatically generates rollback SQL for many change types, including createTable, renameColumn and addColumn. Liquibase states that formatted SQL changelogs do not support automatic rollback generation, so rollback logic must be defined manually for all changesets.
Undo: Redgate states that an undo migration undoes the effects of the versioned migration with the same version, and that undo migrations are optional. Redgate states that Flyway's core commands, including undo (Flyway Teams+), are supported by 50+ DBMS. Choose between the two on the format your reviewers will read in a pull request, the change types you need reversed without a hand-written script, and the license terms your legal team accepts.
The state-based model works from declarations. Microsoft states that SQL projects are based in declarative T-SQL statements, with each object created once in the project code. Microsoft states that the .dacpac publish process calculates the difference between a source .dacpac and a target database before determining what steps it needs to take to update that database. A column split or a backfill is not a difference between two schemas, so state-based deployments need help wherever data moves. Microsoft states that a pre-deployment script is executed before the deployment plan is executed, though the plan is calculated before the script runs, and that a post-deployment script is executed after the deployment plan completes.
Automated checks can stop a change before it is applied. Atlas states that it analyzes every migration for destructive changes, table locks, data loss risks, and concurrent index violations, in CI, on the CLI, or pre-deployment. Microsoft states that the BlockOnPossibleDataLoss property, True by default, terminates the operation during the schema validation step if the resulting schema changes could incur a loss of data. Ask for the full list of checks, which ones block a deployment, and who may override a block.
| Capability | What to test | Why it matters |
|---|---|---|
| Change model | Ordered migration scripts, a desired-state project, or both | Decides who writes the script and what a reviewer reads |
| Pre-deployment checks | Destructive changes, table locks, data loss and backward-incompatible changes | Stops a bad change before it reaches production |
| Rollback | Reverse scripts, computed plans, row copies or a revert window | Decides what can be undone, and for how long |
| Approvals | Rules by environment, risk and change type, tied to the exact script | Evidence of separation of duties |
| Audit record | Who requested, approved and ran each change, with export | Answers an auditor without a manual search |
| Drift detection | Each database compared with its recorded state | Finds changes made outside the pipeline |
| Database coverage | Every engine and managed service you run, feature by feature | Advanced features are often limited to some engines |
| Pipeline fit | Your CI/CD system, source control and secrets store | Avoids a second release process for the database |
Vendors in Database DevOps & Schema Management
Representative vendors include Atlas / Ariga, Bytebase, DBmaestro, Harness, Liquibase, Microsoft SQL Database Projects / SSDT / DACPAC, PlanetScale and Redgate. The list is alphabetical, is not a ranking, and is not for sale. How we choose vendors
Each vendor below is placed by the product it started from. That starting point shapes how it describes a change, what it records, and where it runs.
The migration engines both offer a free edition with different terms. Redgate describes Flyway Community as a free database migrations tool for individual developers and education. Liquibase states that, starting with version 5.0, Liquibase Community is licensed under the Functional Source License, Version 1.1, ALv2 Future License (FSL-1.1-ALv2). Liquibase states that two years after release, the license for each applicable version of Liquibase Community code reverts to Apache 2.0. Read the free edition’s license before building a pipeline on it.
The state-based approach is tied to one database family. Microsoft states that SQL database projects support the SQL Server and Azure SQL family of databases, including Azure SQL Database and Azure Synapse Analytics. Microsoft states that SQL Server Data Tools (SSDT) is a Visual Studio component that provides a graphical interface for SQL projects.
Release automation treats each database change as part of a governed release. DBmaestro states that it is IBM's strategic OEM partner for database DevOps, observability and compliance.
The console approach puts change review and data access in one web workspace. Bytebase describes itself as a unified platform for governing how teams and AI agents access and change any database.
Schema as code applies infrastructure-as-code habits to the database. Ariga states that it builds Atlas, which connects schema changes, permissions, and data operations into a single code-reviewed pipeline. Atlas states that a schema can be defined in any language or ORM, and that Atlas plans, lints, and deploys migrations, declarative or versioned.
The last two approaches start from the delivery platform or the database service. Harness states that its Software Delivery Agent brings database deployments into CD pipelines with governance, rollback automation, and schema drift detection built in. The database service approach is described in the rollback section above.
| Vendor | Approach | Where it fits |
|---|---|---|
| Bytebase | Change and access console | Reviewed changes and data access, with approval flows, row backups and audit logs |
| Harness | Database stage in a CI/CD platform | Database deployments and rollbacks as steps in Harness pipelines |
| Liquibase | Migration engine | Versioned changelogs in SQL or modeled formats, with paid Liquibase Secure plans |
| Redgate | Migration engine | Flyway migrations in plain SQL, with undo in paid editions |
| DBmaestro | Release automation and governance | Governed releases with role rules, downgrade scripts and exportable audit evidence |
| Atlas / Ariga | Schema as code | Schema in code or an ORM, linted in CI, declarative or versioned |
| PlanetScale | Schema change in the database service | Deploy requests with approvals and a revert window on PlanetScale databases |
| Microsoft SQL Database Projects / SSDT / DACPAC | State-based project | Declarative T-SQL projects for SQL Server and Azure SQL |
Eight vendors across seven approaches; Liquibase and Redgate share the migration engine approach. The six vendors from the previous edition stay. Harness was selected to represent a database stage inside a CI/CD platform, and PlanetScale for schema change run by the database service. No row is for sale. The roster check for this edition covered 14 vendors, including open-source migration tools and comparison suites, and any of them can describe its own product in the Spotlight below.
How Are Database DevOps Tools Priced?
Vendors meter different units: developers, database targets, pipeline environments, or plans with a fixed capacity. Ask every vendor to price the same estate: the developers who write changes, the databases each change reaches, and the environments in each pipeline.
DBmaestro states that it is licensed by the number of environments (database/schema connections) in your release pipelines. Liquibase states that Liquibase Secure is packaged in four plans, Starter, Team, Business and Enterprise, each with defined capacity based on database types and database targets. Atlas lists Atlas Pro (Team) starting from $9 per developer, per month, plus usage based pricing for CI/CD pipelines and databases.
Compliance features can sit in a different plan from the core engine. List the features your auditors need, such as approvals, audit export and single sign-on, and have each vendor price the plan that includes all of them.
Free editions carry their own license terms. Have your legal team read them for limits on commercial use and on use by teams, before a free edition becomes part of a production pipeline.
| Meter | You pay for | Grows with | Where it goes wrong |
|---|---|---|---|
| Per developer | Each person who writes or deploys changes | Team size | Service accounts and automated agents counted as users |
| Per database target | Each database the tool deploys to | Environments, regions and tenants | One database per customer multiplying the count |
| Per pipeline environment | Each environment in a release pipeline | Pipeline stages | Short-lived test environments counted as licensed |
| Plan with fixed capacity | A tier with a set number of database types and targets | New database engines | One new engine forcing the next tier |
How Do You Roll Out Database DevOps?
Start with one application on one database engine. Most of the effort goes into bringing existing databases to a known baseline and agreeing who approves which changes. The phases below assume a pilot of about three months.
Capture the current schema of each pilot database in source control. Compare development, test and production, and resolve or record every difference before the first change goes through the tool.
Add the database step to the application’s existing pipeline. Turn on pre-deployment checks, set approval rules by environment, and confirm that the audit record shows the request, approval, script and result for each change.
Run a change that moves data, then undo it on a copy of production data. Record the rollback method for each change type and how long each one took.
Add applications and engines one at a time. Remove direct write access to production once each team works through the pipeline, and review policy exceptions every month.
What should you ask vendors about Database DevOps & Schema Management?
Put these questions in the RFP, and ask for each answer to be shown against a copy of one of your databases.
-
Do you run several database engines?Yes Shortlist migration engines and schema-as-code tools, and check that each engine you run gets the same features.No Include your database vendor’s state-based tools, and compare them with a migration engine on changes that move data.
-
Do auditors review your database changes?Yes Weight approval rules, separation of duties and exportable audit records, and confirm which plan includes them.No Weight pre-deployment checks and the developer workflow.
-
Must a bad change be undone within minutes?Yes Test each tool’s rollback on production-sized data, and write changes as expand and contract so the application can roll back first.No Rely on forward fixes and tested backups, and still keep each change compatible with the running code.