If you've been using Liquibase or Flyway for a while, you already know they solve a real problem. Migrations are tracked. Schema changes are repeatable. Your database evolves in lock-step with your application code.
So why does deploying a database change still feel fragile?
We asked ourselves the same question. We were running Liquibase in production across multiple environments, with a reasonably mature pipeline. Migrations were clean. The versioning worked. But the release — the actual act of getting a change from dev to test to production, with confidence — still had gaps we were plugging with shell scripts, spreadsheets, and hope.
This is the problem drm-cli was built to solve.
What Liquibase and Flyway Actually Do
Let's be precise here, because nothing in this post is a criticism of either tool. Liquibase and Flyway are excellent. We still use them.
What they do: track and apply schema changes. Given a target database and a set of migrations, they work out which changes haven't been applied and apply them in the right order. That's the core job, and they do it well.
What they're not designed to be: a release management layer.
The distinction matters. Version control is about tracking what changed. Release management is about controlling how and when that change reaches each environment — with history, error handling, credential management, and coordination across multiple systems.
The Gaps We Kept Running Into
Here's what we found missing when we tried to treat Liquibase alone as a full release management solution:
1. No release history
Liquibase maintains a DATABASECHANGELOG table per database. That's a migration history. It tells you what migrations have been applied to that database. It doesn't tell you who ran the release, when, from which version of the release package, or whether the release across all your environments succeeded. There's no audit trail at the release level.
2. No encrypted credential management
Your connection strings contain passwords. If you're running migrations from a CI pipeline or a deployment server, those credentials need to live somewhere. Liquibase and Flyway accept them as arguments or environment variables — but they don't provide a mechanism for encrypting them at rest. The moment your pipeline config ends up in a screenshot or a log, you have a problem.
3. No automated retry or failure recovery
A migration fails at step 4 of 12. Now what? Liquibase will tell you what happened. It won't automatically retry the failed step, skip to a recovery path, or log the failure in a structured way that your team can act on without hunting through console output.
4. No multi-solution coordination
Your release touches a SQL Server SSDT project and a Liquibase changelog and a set of Oracle scripts. These are separate tools with separate invocations. Running them in the right order, capturing failures across all of them, and producing a single release record — there's nothing in any one tool that handles this. You write glue code. We all write glue code. Most of it is fragile.
5. No cross-platform release definition
How do you define a release that runs the same way on a Windows deployment server and a Linux CI agent? With Liquibase or Flyway alone, your answer is usually "a shell script on Linux and a batch file on Windows." drm-cli is written in Python and runs identically on both.
Versioning vs. Releasing: A Concrete Example
Imagine you're deploying a change that does all of the following:
- Updates three tables in your SQL Server application database (via SSDT)
- Applies a new Liquibase changelog to a PostgreSQL reporting database
- Runs a post-deployment script that refreshes a materialized view
With Liquibase and Flyway, you have the migration layer covered for the databases they manage. But you're still answering these questions manually:
- What order do these run in?
- What happens if the PostgreSQL migration succeeds but the post-deployment script fails?
- Where is the record of this release — what ran, when, and with what outcome?
- How do I re-run just the failed step without re-running the whole thing?
- How do I pass credentials to each tool without hardcoding them in the pipeline?
These are release management questions. Liquibase isn't trying to answer them. It shouldn't have to. That's a different layer.
What drm-cli Adds on Top
drm-cli doesn't replace Liquibase or Flyway. It wraps and extends them.
You define a release in a YAML file. That file tells drm-cli:
- Which tools to invoke (Liquibase, Flyway, SSDT's
sqlpackage) - In what order
- Against which databases (SQL Server, PostgreSQL, Oracle — or all three)
- With which credentials (stored encrypted, decrypted at runtime)
- With which pre/post scripts to run around each step
drm-cli then executes the release, handles failures with configurable retries, and writes a structured release history entry — regardless of how many tools were involved or how many databases were touched.
Here's a minimal example. A release.yml for a single PostgreSQL deployment using Liquibase:
release:
name: "v2.4.1"
solutions:
- name: reporting-db
engine: liquibase
database: postgresql
changelog: changelogs/reporting/changelog.xml
connection: connections/reporting.enc
That's it for the definition. drm-cli handles the invocation, the logging, and the history.
A Note on What drm-cli Is Not
We want to be honest about scope:
- It doesn't write your migrations for you
- It doesn't manage your Liquibase or Flyway configuration beyond invocation
- It doesn't replace your CI/CD pipeline — it runs inside it
- It's not trying to be an all-in-one database platform
It's a release management layer. Narrow scope, done well.
Getting Started
drm-cli is free and open-source. Installation takes about two minutes.
The interactive installer (the fastest way to get started on any platform) is shown in this walkthrough:
▶️ [drm-cli interactive installation — video]
Or install directly:
pip install drm-cli
The documentation is at [docs link] and the source is on GitHub at [repo link].
What's Next
Next week we'll announce drm-cli v1.1 — which adds full PostgreSQL and Oracle support, Flyway integration alongside Liquibase, and pre/post deployment script support.
If the problem we described here is familiar, the v1.1 announcement is worth watching for.
In the meantime, if you've hit any of these gaps in your own Liquibase or Flyway setup, we'd genuinely like to hear how you've been handling them. Drop a comment below.
drm-cli is built and maintained by d-band. Free. Open-source. No license cost.
Top comments (0)