One Bad Change Shouldn't Cost You the Whole Database

Right now, every organization is living through the same shift. AI is writing more of our code, and it's writing it fast. In his keynote, Jensen Huang from NVIDIA cited data showing the world shipped more code to GitHub in early 2026 than in all of 2025 combined. That's not a trend anymore, it's the new baseline. And when code creation accelerates like that, the pressure lands somewhere. In my experience, it lands on the database, because the database is the one layer that every application, every AI initiative, and every data product depends on.

That pressure creates a very practical problem, one I walked through live in our recent webinar, Undo One Bad Change Without Restoring the Whole Database. Here's the scenario: you ship a release with somewhere between 20 and 40 database changes. A couple of them turn out to be bad. Now what?

The Options Everyone Reaches For First

Most teams handle this one of three ways, and I've seen all three used in production.

• Break glass (full restore). A point-in-time or snapshot restore back to before the bad release. It's guaranteed to work, but it takes every change with it, good and bad, and it means real downtime. It's usually the last resort, but sometimes it's the only option you have.
• Fix forward. Write a new change to patch the bad one and push it through your pipeline. Lower risk than restoring, but slower than it sounds unless you've already built a hotfix pipeline that bypasses your normal gates. And nobody writes their best code under pressure with the business watching.
• Fix it directly in the database. Fast, and it may not require a restore. But now you're testing in production, and you've created drift. If that fix doesn't get backfilled into dev, UAT, and staging, your next deployment either fails somewhere it shouldn't or silently reintroduces the exact problem you just fixed. There's also no governance and no accountability. If someone runs SQL directly against production, is that captured anywhere you can go back and reference? Usually not.

Liquibase Community's Rollback Options Are Still Blunt Instruments

Liquibase Community gives you rollback options that are more structured than raw SQL, but they still aren't precise. There are three ways to roll back.

• Rollback to a tag. Think of a tag like a chalk line drawn before a deployment. Roll back to it, and you undo everything after it, good or bad. And if the row holding your tag gets rolled back, you lose the tag too.
• Rollback count. Undo the last N changes. It's a shotgun. Unless your bad changes happen to be the very last ones deployed, you're taking out good changes right along with them.
• Rollback to a date. Same idea, different trigger. Everything inside that time window is fair game to be rolled back, whether it needed to be or not.

All three of these are all-or-nothing. That's the gap Liquibase Secure was built to close.

Two Ways to Do This Surgically

Liquibase Secure adds two rollback options that let you go after the specific change that broke something, and leave everything else exactly where it is.

• Rollback one changeset. This is a scalpel, not a shotgun. It doesn't care where the bad change sits in your sequence or when it was deployed. If change 2 and change 30 out of 40 are bad, this removes exactly those two and leaves the other 38 untouched.
• Rollback one update. Every time you run a Liquibase update, it gets a deployment ID. This lets you roll back that entire deployment as a unit, a cleaner replacement for tag-based rollback in most cases.

What This Looked Like Live

In the demo, I ran the same scenario two ways: once with a state-based comparison tool (a DACPAC, in this case), and once with Liquibase.

On the DACPAC side, I had a grant statement already sitting in the database: a reporting role with select access to an orders table. I deployed my release. Everything looked fine, until I checked and found the grant statement was gone. That's the risk with state-based tools: they bring the database to a desired end state, and anything not explicitly defined in that end state can get quietly torn down along the way, even if it had nothing to do with the release. I then deployed a hotfix for an unrelated application error. The hotfix worked. The grant statement stayed missing. State-based tools don't know something is supposed to be there once it's gone; they just see that it's absent, and they leave it that way.

Now the Liquibase side. Same setup, same grant statement in place. I ran my update: five changes deployed successfully, grant statement still there. Then I hit the same application error and needed to roll back one specific change. Instead of restoring the whole database or hoping a fix forward wouldn't break something else, I ran a targeted rollback on just that one change. My application went back to healthy. And when I checked, the grant statement was still exactly where it should be. It was never touched, because the rollback only touched what it was supposed to touch.

That's the whole point. No splash damage. No collateral changes. Just the one thing that needed to be undone.

Why This Matters Beyond One Demo

Database DevOps tends to lag behind application DevOps, and it's not because teams don't care. It's because the stakes feel different. A database often feeds other systems, other teams, other reports downstream, so the instinct to be cautious is a good one. The problem is that caution usually shows up as manual review and manual fixes, and that doesn't scale as AI accelerates how fast changes get proposed in the first place.

This is really what we mean when we call Liquibase Secure a control plane for database change. You keep the same level of control you have today, you just get better visibility and automation layered on top of it. Customers using Liquibase Secure have reported meaningful reductions in deployment risk, stronger audit readiness, and deployments running significantly faster than their previous manual process. When you get that kind of time back, the conversation changes. Instead of reviewing scripts, your DBAs and platform teams can spend that time on the work that actually moves the business forward.

Rollback Options at a Glance

Here's how all eight approaches stack up side by side.

* Rollback runs against the live database, so a heavy change (like rebuilding a big index) can be just as slow to undo as it was to apply

Where This Is Headed

One thing worth adding, since a few people asked about it during Q&A: this works the same way across Liquibase's 65-plus supported database platforms. The same targeted rollback command I ran against SQL Server in the demo works the same way against Oracle, Snowflake, or MongoDB. That consistency is the point. If your organization is running Postgres in one place, SQL Server in the cloud, Mongo Atlas somewhere else, and Snowflake or Databricks for your data team, standardizing how you deploy and roll back changes means everyone in the organization is speaking the same language, no matter which database they're touching.

Live Q&A from the Webinar

A few of the questions our live audience asked during Q&A. I've kept these in my own words, the way I answered them on the call.

What is Liquibase, in a nutshell?

I'd describe it as DevOps for your database. At its core, Liquibase versions, tracks, and deploys your database changes, the same mental model you already use for application code. Liquibase Secure layers policy checks, change intelligence, audit capabilities, and drift detection on top of that core.

Is rollback one changeset available in Community, or only Secure?

Only in Secure. Community does give you rollback options, but they're closer to a shotgun: tag, count, or date based. You're likely to catch a few extra changes along with the one you actually needed to undo.

Does targeted rollback work the same way across different databases?

Yes. That's one of the real advantages of Liquibase supporting 65-plus platforms. I can run the exact same rollback one changeset command whether I'm working in SQL Server, Oracle, Snowflake, or Mongo.

How are rollback scripts actually created?

There are three ways. If you're writing raw SQL, you write your own rollback instructions, which could be as simple as a drop table to reverse a create table, or something more nuanced like renaming a table instead of dropping it. If you're using our modeled change types (YAML, JSON, XML), Liquibase can generate the reverse operation automatically at runtime. And with generative AI, our MCP server for Liquibase Secure can generate the rollback statements too, validated against Liquibase standards, though I'd always keep a human reviewing anything AI generates.

Can I test a rollback script before I actually need it in production?

Yes, and it's one of our recommended best practices. In non-production environments, run your update, then run the rollback, confirm the database lands back where it started, then reapply the update. Liquibase Secure also has a built-in policy check that can require a rollback script to be present before a change is allowed to deploy.

What happens to the code in my repository after I roll back a change?

The rollback itself only addresses what's live in the database. You'll still need to remove that change from your changelog artifact in the repository, or it will simply get redeployed the next time you run an update. That cleanup is a normal part of any rollback.

What does the audit trail actually look like?

There are four layers to it. The database changelog history table records every operation Liquibase performs, successful or not. Operation reports are HTML summaries you can distribute automatically. JSON formatted logs can feed into a tool like Datadog or Splunk. And Change Intelligence, our visibility platform coming later this year, ties all of that together in one place.

What do I need in place to run rollback one changeset?

Three pieces of metadata: the change's ID, the author, and the changelog file it lives in. That's how Liquibase uniquely identifies a change and knows exactly what to undo.

How should I organize my changelog folders?

Most of our customers do it one of two ways: by release, where each release has its own folder with everything that shipped in it, or by object type, where every change to a given table or view lives in one file so you can see how that object evolved over time. Both work. It depends on whether you care more about seeing an entire release at once or the history of a single object.

Do I have to use the CLI, or is there a UI for rollbacks?

Today it's CLI only. Most of our customers wrap that inside a pipeline, though, using something like GitHub Actions or Azure DevOps. That gets you a friendlier prompt instead of a long command, and just as important, it gives you a governed, auditable record of who ran a rollback and when.

‍Get a Free Database Change Audit

If you're dealing with any of the scenarios I walked through here, whether it's downtime from a bad release, drift between environments, or gaps in your audit trail, we're offering a free database change audit. We'll look at what's actually happening in your environment and help you figure out the best path forward. Book time with us here.