dband drm

Posted on Apr 10

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

#postgres #database #devops #opensource

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.

DEV Community