The Problems with Liquibase Rollback — and What to Do Instead

A common question we get: why doesn’t SQLcl Projects support Liquibase rollback? At first glance, Liquibase’s rollback feature seems like a great safety net. Not only can it evolve your schema forward, it promises to take you backward if something goes wrong during a deployment.

That sounds ideal—until you try to rely on it.

The truth is, Liquibase rollback is a false promise. And the last time you want to learn that is in the middle of a production deployment.

Why Liquibase Rollback Fails in Practice

If databases only contained DDL objects—like tables, constraints, and indexes—rollback could work in theory. Create a table? Drop it to undo. Add a constraint? Remove it to reverse the change. Even for soft objects like packages, triggers, and views, redeploying a previous version can roll you back in time.

But here's the catch: rollback statements don’t write themselves. Developers have to create them—and test them. And if you've ever been on a team managing database changes, you know it's hard enough to get the forward DDL right, tested, and deploy-ready.

Do you really think the rollbacks are getting the same attention?

Even if you set up automated tests for rollback logic in your CI/CD pipeline (and kudos if you do), you’ll quickly run into a deeper problem: data.

The Real Limitation: Data

As soon as data changes enter the mix, things fall apart. Recreating a dropped column is easy—but restoring the exact data it once held? Not so much.

Liquibase isn’t designed to manage transactional consistency or complex data restoration. Some things just can’t be rolled back. Not without proper tooling and planning.

So what should you do?

The Right Way to Roll Back

If you’re thinking about rollback strategies, then you should also be thinking about offline upgrades—that is, taking the application offline and ensuring no transactions (scheduled jobs, background processes, ad hoc DML) are running during the upgrade.

Yes, some teams resist downtime. But unless you’re working under strict SLAs that prohibit it, taking the downtime hit is usually safer and simpler than attempting an “always-on” deployment.

Oracle Database offers powerful features that can support real rollback strategies—tools that go far beyond what Liquibase can provide.

1. Flashback Database

Oracle Flashback allows you to restore the entire database (or PDB) to a previous point in time. It's simple and fast—as long as your application is the only one using the database.

You take the app offline, note the timestamp, begin the upgrade, and if something goes wrong, flash back to the moment just before you started. Done.

Just be sure to configure your flashback retention (DB_FLASHBACK_RETENTION_TARGET) and fast recovery area size accordingly—and test the whole process.

2. Database Restore

Restoring from backup is another option, though it’s slower and less convenient than Flashback. The advantage? You can go further back in time.

If Flashback is available and meets your recovery window, it’s usually the better choice.

3. Data Pump (expdp / impdp)

When you’re working in a shared database and can’t flash back the entire environment, Data Pump offers a schema-level solution.

Export your application schemas before the upgrade, and if something goes wrong, import them back. This works best when your schemas don’t contain large amounts of data—performance and feasibility drop quickly as data volume increases.

The Right Way to Roll Forward

Some teams adopt a “roll forward and fix it live” strategy. That can work—if you’re doing an offline upgrade. If something goes wrong, no users are impacted, and you can fix the issue and resume.

But if you're upgrading online, things get riskier. A failed deployment during business hours can mean unplanned downtime, user disruption, and high-stakes fire drills.

As with rollback, Oracle provides the tools to help you roll forward the right way.

1. Edition-Based Redefinition (EBR)

EBR lets you maintain multiple versions of application objects side-by-side within the same schema. You can deploy a new version of your code while users continue using the old one—and switch them over when you're ready.

This is the gold standard for zero-downtime upgrades in Oracle Database.

2. Online Redefinition (DBMS_REDEFINITION)

Need to change a table’s structure without locking it? DBMS_REDEFINITION lets you redefine large tables online, with minimal impact to users. It’s a great way to roll forward without taking your application offline.

Conclusion

Liquibase rollback sounds appealing—but in practice, it’s incomplete and risky. DDL is hard enough to manage. DML? Nearly impossible to roll back reliably.

For most teams, an offline, “roll forward and fix it live” approach is usually sufficient—especially when paired with strong testing and a reliable rollback plan. Instead of trying to make Liquibase do something it’s not designed to do, lean on Oracle’s native features for safe, reliable rollback and roll-forward strategies. Plan for offline upgrades when possible. Use Flashback, restore, or Data Pump for rollback. For online upgrades, adopt Edition-Based Redefinition or DBMS_REDEFINITION.

The best deployment plan is the one that lets you recover confidently—before something goes wrong.