Liquibase can automatically generate rollback SQL for many Change Types, such as createTable, renameColumn, and addColumn. If your changelog only uses these supported Change Types, you do not need to manually define rollback logic—Liquibase will handle it for you when you run the rollback command.

However, not all Change Types support automatic rollback. For example, dropTable, insert, and all formatted SQL changesets do not have a clearly defined inverse operation, so Liquibase cannot generate rollback SQL for them. In these cases, you must provide custom rollback logic inside the changeset.

Note: When rolling back stored logic, Liquibase does not restore the previously stored version. Instead, Liquibase rolls back to the exact file/code specified in the custom rollback.

You can also override the default rollback even for Change Types that do support auto rollback, giving you more control over how your database is restored.

You can use automatic rollback with XML, JSON, and YAML changelogs for any Change Type marked as "Supported" in What change types can I use auto rollback with?

For any change that you'd like to add rollback to, add a <rollback> tag inside the <changeSet> tag.

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.

You can also specify multiple Change types within a single <rollback> statement or across multiple <rollback> statements