What is a rollback?
Last updated: June 10, 2026
A rollback in Liquibase reverses changes that have been deployed to your database. You can roll back changes to a previous state based on a tag, a date and time, or a specific number of changesets. When Liquibase rolls back a changeset, it removes the corresponding row from the DATABASECHANGELOG table.
Before you can use rollback commands, you need to have your Liquibase project set up. You'll need to make sure you have a liquibase.properties file that specifies the driver, classpath, and URL. You may also need to set up any needed authentication so Liquibase is connected to your database.
If you use modeled changelogs (XML, YAML, JSON), you can define custom rollback logic for your changesets. Custom rollback definitions are not supported in formatted SQL changelogs. You must write rollback SQL manually in the changelog file.
For rollback command syntax and usage examples, see rollback.
Rollback commands
Command | Description | Edition |
|---|---|---|
This command will revert all changes made to the database after the specified tag. It is used when you want to undo a series of changes related to a specific tag, such as a numbered release. | All editions | |
This command is used to revert all changes made to the database from the current date to the date and time you specify. There are several ways to revert your changes with the rollback-to-date command.There are three options: You can use YYYY-MM-DD, HH:MM:SS, or YYYY-MM-DD'T'HH:MM:SS formats to specify the rollback date, time, or date + time. You can also specify date or time only.Examples: rollback-to-date YYYY-MM-DD, rollback-to-date HH:MM:SS, or rollback-to-date YYYY-MM-DD’T’HH:MM:SS | All editions | |
This command is used to roll back a specified number of changesets, where <value> is the number of changesets you want to revert sequentially on your database. The command will rollback the changes sequentially starting with the most recent changes. | All editions | |
This command will revert one non-sequential changeset made during a previous database change without affecting any other changes made to your database. | Liquibase Secure | |
This command will revert all changesets related to a specific deploymentId that was made during a previous database change. The command will undo a series of changes made to the database during a specific deployment and revert those changesets to their previous state without affecting any other changes made to the database. | Liquibase Secure |
Validating rollbacks
Rollback scripts are one of the most challenging aspects of application development to create and maintain, especially when data is modified.
If the database change is simple, such as adding a new index or updating a stored procedure, then the rollback is straightforward.
Rolling back complex changes that involve structural changes and data migration is more difficult.
So, before performing a rollback, it is important to validate the changes Liquibase will run before making the change to the database. These
Command | Description | Edition |
|---|---|---|
This command is used to test rollback functionality when deploying changesets in your changelog sequentially. It tests the rollback by deploying all pending changesets, executing a sequential rollback in reverse order for the deployed changes, then running the update again. | All editions | |
This command produces the raw SQL that Liquibase would use to revert changes associated with undeployed changesets. It is used when auditors need to verify that all database changes have a rollback. | All editions | |
This helper command is used in conjunction with the rollback<tag> command to inspect the SQL Liquibase will use to revert changes associated with the tag you specify. | All editions | |
This helper command produces the raw SQL Liquibase would need to roll back all undeployed changes made up to the specified tag. | All editions | |
This helper command is used in conjunction with the rollback-to-date command to inspect the SQL that Liquibase will run when using the rollback-to-date command. | All editions | |
This helper command is used in conjunction with the rollback-count <value> command to inspect the SQL Liquibase will use to rollback changes based on the value specified. | All editions | |
This helper command produces the raw SQL Liquibase would use to roll back a specified number of undeployed changes that have been added to the changelog. | All editions | |
This helper command is used in conjunction with the rollback-one-changeset command to inspect the SQL Liquibase will use to rollback changes based on the specified changeset. | Liquibase Secure | |
This helper command is used in conjunction with the rollback-one-update command to inspect the SQL Liquibase will run to revert all changesets associated with the deploymentId specified in the rollback-one-update command. | Liquibase Secure |
Rollback test cycle
Rollback scripts need to be tested just like application code, so we know they work as designed.
You will need to test your rollback scripts carefully. This includes determining who will test the rollback script, how and when they will be tested.
A complete test cycle should include
Deploying all changes to the database and validating that they were deployed.
Rolling back all changes to the database, validating that all changes were reversed, and verifying that the database was brought back to the previous state.
Redeploying all changes to the database. This is required to verify that the rollback did not miss any changes that could impact a future deployment.
Using external rollback files
For complex rollback logic like stored procedures, you can reference external rollback script files using --rollbackSqlFile. This approach is beneficial when rollback logic is extensive or when you want to keep rollback scripts organized in separate files.
In this example, you would replace my_path/my_rollback.sql with the path to a SQL file containing your rollback instructions for that changeset.