Liquibase® version 3.8.2 is now available! Get it for free.
2018 XML Announcement
News 5 Ways to Fix a Bad Database Change in Liquibase
04 Dec 2019

- and/or -

All Previous Posts >>

Liquibase for DBAs

No change is forgotten

Liquibase tracks which changelog statements have run against each database, so you no longer have to manually track what statements have been run against each database and which have not.

Like SQL? Use SQL

XML-formatted changelogs have their advantages, but many DBAs still prefer good, old fashioned SQL. If that is what you are most comfortable working with, Liquibase-formatted SQL gives you the standard changeSet tracking used in any changelog format, but lets you specify the exact SQL you want.

Manually verify the database changes with each release

Liquibase supports an “updateSql” command which will not actually update the database, but instead output the SQL that will run. That script can be read through and verified to ensure everything is correct and doing what it is supposed to.

After you know everything is correct, you can either run liquibase update, or run your script through your favorite tools. The script will include the DATABASECHANGELOG inserts so everything will still be correctly tracked.

Prepare for deployment problems

Releases don’t always go as planned, and so Liquibase lets you ensure your contingency plans are correct before each release. As you near a release, besides checking the updateSql output, you can also run futureRollbackSql which will output the SQL needed to bring a fully updated database back to the current state. It will be much less stressful verifying the rollback logic BEFORE the release.

A unified changelog for all your databases

You try to keep all your databases the same, but there are always differences. QA needs test data, production gets a couple extra tables, and the hot-backup server needs extra configuration. Liquibase supports contexts, labels, parameters, and preconditions that let you address minor differences in your scripts to adjust things as needed.

  • Contexts and labels let you target certain changeSets to run in only some environments.
  • Parameters let you do simple text substitutions when things like schema names vary from database to database.
  • Preconditions let you check the state of the database to dynamically determine if a changeSet should be executed or not.

Thanks to Liquibase’s [cross-database support](/databases.html, you can even use a single changelog that supports Oracle, MS SqlServer, Postgresql, and more.

Enterprise features with Datical

Beyond all the standard Liquibase functionality, Datical lets you


Liquibase for QA | Developers | Release Managers