DEV Community: dband drm

drm-cli v1.1 is out — PostgreSQL, Oracle, Liquibase & Flyway now supported

dband drm — Fri, 10 Apr 2026 05:15:31 +0000

We shipped drm-cli v1.1 this week.

If you haven't heard of drm-cli before: it's a free, open-source database release manager that layers on top of your existing tools — Liquibase, Flyway, SSDT — and adds release history, encrypted credentials, automated retries, and multi-solution deployments. It doesn't replace your migration toolchain. It wraps it and fills the gaps that migration tools were never designed to fill.

v1.0 supported SQL Server via SSDT and sqlpackage. That covered a lot of ground for us, but it wasn't enough.

Here's what changed in v1.1.

What's new in v1.1

PostgreSQL support

drm-cli now supports PostgreSQL deployments via Liquibase or Flyway. You configure your solution with db_type: postgresql, point it at your changelog or migration directory, and drm-cli handles the rest — connection string encryption, release history tracking, retry logic, pre/post scripts.

Same release model you'd use for SQL Server, now for Postgres.

Oracle support

Oracle deployments via Liquibase or Flyway are now supported. If you've ever tried to wrangle Oracle connection strings, schema differences, and deployment sequencing across environments, you know why this matters. drm-cli treats Oracle the same as any other database in the release — same config structure, same audit trail, same retry behavior.

No separate toolchain for Oracle. No separate release process.

Liquibase and Flyway integration

v1.0 relied on sqlpackage for SQL Server. In v1.1, Liquibase and Flyway are first-class execution engines.

You configure which engine to use per solution. drm-cli invokes it, captures the output, evaluates success or failure, and records the result. If something fails, the retry logic kicks in. The audit trail captures what ran, when, and what the outcome was — regardless of which engine executed it.

If your team already uses Liquibase or Flyway, drm-cli doesn't ask you to change that. It sits on top of what you already have.

Pre/post deployment scripts

This one came directly from operational pain.

Before deploying, you might need to run a notification script, disable a job, or snapshot something. After deploying, you might need to re-enable that job, run a smoke test, or hit an API. These steps are easy to forget, easy to skip under pressure, and expensive when missed.

v1.1 introduces pre_scripts and post_scripts at the solution level. You define the scripts once. drm-cli runs them every time, in order, before and after the main deployment — regardless of which database or execution engine is involved.

We'll cover the pre/post pattern in depth in a dedicated post in Week 6. For now: the short version is that anything you'd put in a "don't forget to" comment in your runbook should be a pre/post script instead.

Encrypted connection strings (extended)

Credential encryption was in v1.0, but v1.1 extends it to cover PostgreSQL and Oracle connection strings. The mechanism is the same — drm-cli can encrypt your connection strings at rest and decrypt them at deploy time. No plaintext credentials sitting in your release config.

The video linked below walks through a deployment using encrypted credentials end-to-end.

What stayed the same

The core model hasn't changed. drm-cli reads a release config, executes solutions in order, tracks the result of each one, and writes the history to a release log. If a solution fails, it retries. If it fails past the retry threshold, it stops and reports.

v1.0 users can upgrade without changing their existing config. The only required change is adding db_type if you're adding a new PostgreSQL or Oracle solution — existing SSDT solutions default to their previous behavior.

We'll write the full upgrade guide in Week 8. The short version: it's a pip install and an optional config update.

Quick look at the v1.1 config

Here's what a basic v1.1 release config looks like with mixed database types:

release:
  name: "Q2-2026-release-01"
  solutions:
    - name: "core-schema"
      db_type: sqlserver
      tool: ssdt
      dacpac: "./build/CoreSchema.dacpac"
      connection_string: "encrypted:<cipher>"

    - name: "analytics-db"
      db_type: postgresql
      tool: liquibase
      changelog: "./liquibase/changelog.xml"
      connection_string: "encrypted:<cipher>"

    - name: "reporting-oracle"
      db_type: oracle
      tool: flyway
      migration_dir: "./flyway/migrations"
      connection_string: "encrypted:<cipher>"
      pre_scripts:
        - "./scripts/pre/disable_job.sh"
      post_scripts:
        - "./scripts/post/enable_job.sh"

SQL Server, PostgreSQL, and Oracle. Three different execution engines. One release. One audit trail.

How to install or upgrade

New install:

pip install drm-cli

Upgrade from v1.0:

pip install --upgrade drm-cli

Verify the version:

drm --version

You should see drm-cli 1.1.x.

The full release notes are on the drm-cli GitHub repo. Open issues and feature requests there.

What's coming in the next few weeks

Over the next several posts we'll go deep on each of the new capabilities:

Week 4 — Step-by-step: deploying to PostgreSQL with Liquibase or Flyway
Week 5 — Oracle deployments without the enterprise license overhead
Week 6 — The pre/post script pattern in detail

If you're already using drm-cli and upgrade to v1.1, let us know how it goes. If you hit anything unexpected, open an issue. We read them all.

And if this is the first time you're hearing about drm-cli — the Week 2 post covers the problem we built it to solve. Start there if you want the full context before diving into v1.1.

drm-cli is free and open-source. No license tiers, no paid features, no freemium model. Everything described here is available to everyone.

The Gap Between Database Version Control and Release Management

dband drm — Thu, 02 Apr 2026 16:15:00 +0000

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.

We're d-band — Here's Why We Build Open-Source Tools

dband drm — Mon, 23 Mar 2026 16:12:01 +0000

This is the first post from d-band. We're not launching a product today. We're introducing ourselves.

We Built What We Needed

A few years ago, we were running database deployments across multiple environments, multiple databases, and multiple tools. Liquibase for one system, SSDT for another, custom shell scripts to glue it all together, a shared spreadsheet to track what actually deployed where.

It worked. Until it didn't.

The spreadsheet went stale. Scripts diverged between environments. A rollback that should have taken ten minutes took three hours because nobody could say with confidence what state the target database was actually in.

We looked for a tool that could tie all of this together — something that sat on top of the tools we already had, tracked deployment history properly, handled credentials securely, and let us run a full release across multiple databases without stitching together a dozen scripts.

We didn't find one that hit all of those marks without a significant license cost or a full platform migration.

So we built one.

Who We Are

d-band is a small team of data engineers and DevOps practitioners. We do consulting work — helping organizations build and maintain data infrastructure — and alongside that, we build tooling.

We're not a VC-backed startup optimizing for growth metrics. We're practitioners who got frustrated with a gap in the ecosystem and decided to fill it.

That gap is database release management. Not version control — that problem is largely solved. Release management: the process of taking your versioned schema changes and actually getting them deployed, reliably, with a full audit trail, across all the databases you care about.

What We Believe

A few things we think are true about tooling in this space:

Open-source is the right model. Database tooling has a long history of "free tier, enterprise price." We think that creates the wrong incentives. When a tool is fully free and open-source, the authors have to earn trust through quality, not through feature gating.

Don't replace what works. Liquibase and Flyway are good tools. SSDT is genuinely useful for SQL Server shops. We're not interested in building a competitor to those tools — we're interested in building the layer above them that handles the parts they don't.

History matters. Every deployment should be recorded. Not in a log file that someone might or might not check — in a queryable release history that's part of your workflow. When something goes wrong at 2am, you should be able to answer "what changed, when, and where" in under a minute.

Security shouldn't be an afterthought. Connection strings containing credentials shouldn't live in plaintext config files. This is obvious in principle and routinely ignored in practice. We built credential encryption into drm-cli from the start.

What We're Releasing

Our first public tool is drm-cli — a free, open-source database release manager that layers on top of Liquibase, Flyway, and SSDT.

It handles:

Release history tracking — every deployment recorded, queryable, auditable
Encrypted credentials — connection strings encrypted at rest
Automated retries and failure recovery — deployments that recover gracefully when something transient goes wrong
Multi-database releases — SQL Server, PostgreSQL, and Oracle in a single coordinated release
Pre/post deployment scripts — steps that always run before or after every deployment
Cross-platform — Windows, Linux, macOS

We're not going to go deep on any of those today. Each of them deserves its own post, with real config examples and real commands. That's what's coming over the next several weeks.

Why Post Here

We're building in public because we think that's how open-source tooling should work.

Over the next few weeks, we'll be posting technical tutorials, honest write-ups of what we got wrong and had to rethink, and a full walkthrough of what drm-cli v1.1 can do. Not press releases — actual technical content that's useful whether or not you ever touch our tool.

If any of this is relevant to problems you're dealing with, follow along. We'd rather earn readers through useful content than through a product announcement.

Where to Find Us

GitHub: github.com/d-band/drm-cli — the repo, the docs, and the issue tracker
drm-cli docs: full documentation is in the repo
This blog — we'll be posting here regularly

Next week: what drm-cli actually is, what problem it solves, and why Liquibase and Flyway alone aren't enough for release management.

We're d-band. We build things we need. If you need them too, that's a bonus.

What's your biggest database deployment pain point?

dband drm — Sat, 14 Feb 2026 15:17:48 +0000

After spending countless hours debugging database deployment drift across multiple databases on different environments, we decided to build something better.

The problem was simple but painful:
→ Juggling multiple deployment tools for Oracle, PostgreSQL, SQL Server
→ No unified interface for database releases
→ Manual tracking of what's deployed where
→ Deployments failed with no retry mechanism
→ Team wasted hours tracking down issues

So we built DRM-CLI - a unified Python CLI that:
✓ Single interface for Oracle, PostgreSQL, SQL Server
✓ Built-in retry mechanism for resilient deployments
✓ Parallel execution for multiple targets
✓ Complete deployment tracking (SQLite or JSON)
✓ Secure encryption for sensitive configs
✓ Integrates with Flyway, Liquibase, sqlpackage

Built with Python for cross-platform support (Windows & Linux)
Open source under MIT license

The response from our DBA team has been incredible - we're deploying faster and catching issues before they hit production.

If you're managing database deployments across multiple environments, check it out:
🔗 https://github.com/dband-drm/drm-cli
🔗 https://www.linkedin.com/company/d-band
🔗 https://www.d-band.com/

What's your biggest database deployment pain point?

Database #DevOps #DBA #Oracle #PostgreSQL #SQLServer #OpenSource #DataOps