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.
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.
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.
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.
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.
Thanks to Liquibase’s [cross-database support](/databases.html, you can even use a single changelog that supports Oracle, MS SqlServer, Postgresql, and more.
Beyond all the standard Liquibase functionality, Datical lets you