Why We Built DRM: Stopping Production Incidents Caused by Manual Database Deployments By Alexey Levin & Eli Shohat, co-founders of D-Band ---

Between the two of us, we have spent over 25 years as DBAs. We have worked across industries - finance, healthcare, logistics - and across database platforms: MSSQL, Oracle, PostgreSQL. And in all that time, one thing never changed: deploying database releases was still a manual, nerve-wracking process that nobody had truly solved. This is the story of why we built DRM.

The problem nobody talks about out loud

If you have ever been a DBA on a release night, you know the feeling. It is 11 PM. The application team is waiting. You have a script - or maybe a folder of scripts - that somebody wrote, reviewed, and hopefully tested. You connect to production, take a deep breath, and run it. Sometimes it goes perfectly. Sometimes it does not.

The thing is, most post-mortems after a database incident point to the same root causes:

• A script ran out of order
• A script ran twice (it was not idempotent)
• Someone deployed to the wrong environment
• The deployment worked in staging but failed in production because of a data difference nobody accounted for
• A rollback had to be done manually, under pressure, at 2 AM

We have been in every one of those situations. And every time, after the dust settled, someone would say: "We need a better process." Then the next release cycle would start, and the process would be exactly the same as before.

Why existing tools did not solve it

We looked at what was available. Flyway and Liquibase are great migration tools - but they are designed for schema changes, not full database release management. They do not handle stored procedures, views, and data seeding the same way. They do not give you a dry-run that shows you exactly what will execute before you commit to it. And they require you to already have a CI/CD pipeline in place before they add any value.

Azure DevOps release pipelines and GitHub Actions can orchestrate deployments, but they leave the database-specific logic entirely to you. You end up writing fragile shell scripts that wrap sqlcmd or psql, and the next person who joins the team has no idea how any of it works.

What was missing was a dedicated tool that thought about database releases the way a DBA thinks about them - not as a side effect of application deployment, but as a first-class operation that deserves its own workflow, its own safety checks, and its own audit trail.

The moment we decided to build it

The decision crystallized during a production incident at a client site. A deployment script had been tested and signed off on in staging. When it ran in production, it hit a constraint violation that nobody had anticipated - because production had data that staging did not. The fix took four hours. The business impact was significant.

Afterwards, we sat down and drew out what a better tool would look like. The core idea was simple: before any script touches production, you should be able to see exactly what it will do - on that specific environment, against that specific data - without actually doing it. That is the dry-run principle that became the foundation of DRM.

What we built

DRM (Data Release Manager) is a CLI tool for managing database releases across MSSQL, PostgreSQL, and Oracle. The workflow is straightforward:

1. Define your release - a release is a versioned set of SQL scripts, organized and managed through the DRM database.
2. Dry-run before you commit - drm-cli deploy -c production -r release-42 --dryrun generates every script that would execute, in order, without running anything. You review the output. You catch the issue before it becomes an incident.
3. Deploy with confidence - drm-cli deploy -c production -r release-42 --deploy runs the release. Every step is logged. Every action is auditable.
4. Align when needed - drm-cli deploy -c production -r release-42 --align brings a database up to a specific release state without a full redeploy. Useful when environments drift.

Credentials are AES-encrypted. The tool integrates with GitHub Actions and Azure DevOps. And as of v1.2.0, it ships with an AI layer - an MCP server and a natural-language agent - so you can query your release state and get deployment guidance through Claude.

The result

Since adopting DRM, the teams we have worked with have seen 50% reductions in deployment time and cost. More importantly, they have seen zero production incidents caused by deployment errors - because the dry-run step catches problems before they reach production.

That is what we set out to build. We think every DBA and DevOps team working with SQL databases deserves a tool like this.

Try it

DRM is available now:

npm install -g @d-band-drm/drm-cli
drm-cli --version

• GitHub: github.com/dband-drm/drm-cli
• Website: d-band.com
• Questions: dband.drm@gmail.com

We are actively developing DRM and would love to hear from teams dealing with the same problems we described here. If this resonates, star the repo or reach out - we read every message.

Alexey Levin and Eli Shohat are co-founders of D-Band and the creators of drm-cli. Combined, they bring 25+ years of DBA experience across enterprise database platforms.