`rollback`

The rollback command rolls back changes made to the database based on the specified tag.

Uses

The rollback command is typically used to revert all changes that were made to the database after the tag you specify.

When you run rollback, Liquibase will roll back sequentially all the deployed changes until it reaches the tag row in the DATABASECHANGELOG table. For example, you can use the rollback command when you want to undo a series of changes made to your database related to a specific tag such as a numbered release. If you have tags for release 1, release 2, and release 3, and need to make a correction in release 2, the rollback command will rollback release 3 first.

The following image shows that if we deploy the createTable C changeset and run the rollback --tag=version1 command to revert changes, Liquibase will roll back only createTable C value:

Impact

Using the rollback command comes with risks to your database, so it's important to look for potential unintended consequences before executing this command. You can do this with the rollback-sql command.

Syntax

To run the rollback command, specify the driver, classpath, and URL in the Liquibase properties file. For more information, see Create and Configure a liquibase.properties File. You can also specify these properties in your command line.

Also, before running the rollback command, you need to know the following:

If the tag name is unknown to you, you can find it in the DATABASECHANGELOG table.
If you don't have any tags specified, you can run the tag command. If you run the tag command to mark the current database state or release, your tag will be applied to the last row in the DATABASECHANGELOG table.
If you use the tagDatabase Change Type to create a tag changeset in the changelog file and want to roll back changes applied after this tag, the rollback command will remove all changes made after this tag row and the tag row.
If you run the tag command, deploy changesets, and then add the tagDatabase Change Type in your changelog file, your changes and the tag row created by the tagDatabase Change Type will be removed till the command reaches the tag specified with the rollback command.

liquibase rollback --tag=myTag --changelog-file=example-changelog.xml

Note: The --tag=myTag syntax was added in Liquibase 4.4. If you use an older version, specify your tag as a positional argument: <command> myTag.

Command parameters

Attribute	Definition	Requirement
`--changelog-file=<string>`	The root changelog	Required
`--tag=<string>`	The tag identifying which tagged changesets in the changelog to evaluate. Specify as `--tag=myTag`. Positional format `<command> <tag>` deprecated in 4.4+.	Required
`--url=<string>`	The JDBC database connection URL. See Using JDBC URL in Liquibase.	Required
`--change-exec-listener-class=<string>`	Fully-qualified class which specifies a `ChangeExecListener`. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`--change-exec-listener-properties-file=<string>`	Path to a properties file for the `ChangeExecListener` class. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`--context-filter=<string>`	Specifies the changeset contexts to match. Contexts are tags you can add to changesets to control which changesets are executed in any particular migration run. Note: If you use Liquibase 4.23.0 or earlier, use the syntax `--contexts` instead of `--context-filter`.	Optional
`--default-catalog-name=<string>`	Name of the default catalog to use for the database connection	Optional
`--default-schema-name=<string>`	Name of the default schema to use for the database connection. If `defaultSchemaName` is set, then objects do not have to be fully qualified. This means you can refer to just `mytable` instead of `myschema.mytable`. Tip: In Liquibase v4.23.0+, camelCase for `defaultSchemaName` works successfully. If you are on an earlier version, camelCase may not work as expected. Note: The syntax `liquibase.command.defaultSchemaName` is valid for v4.19.0+. For prior versions, use `defaultSchemaName`.	Optional
`--driver=<string>`	The JDBC driver class	Optional
`--driver-properties-file=<string>`	The JDBC driver properties file	Optional
`--label-filter=<string>`	Specifies the changeset labels to match. Labels are tags you can add to changesets to control which changesets will be executed in any migration run.	Optional
`--password=<string>`	Password to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional
`--rollback-script=<string>`	The path to the script to use to perform the rollback. Only needed if the rollback is not already defined in the changelog, and if it is not a rollback statement that is automatically generated by Liquibase.	Optional
`--tag-version=<string>`	Tag version to use for multiple occurrences of a tag. Valid values are `NEWEST` and `OLDEST`. If set to `NEWEST`, Liquibase rolls back changes up to the most recent instance of the tag. Any older instances of the tag remain in the DATABASECHANGELOG table. If set to `OLDEST`, Liquibase rolls back changes up to the first instance of the tag. Default: `OLDEST`	Optional
`--username=<string>`	Username to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional

Attribute	Definition	Requirement
`cmdArgs: { changelog-file: "<string>" }`	The root changelog	Required
`cmdArgs: { tag: "<string>" }`	The tag identifying which tagged changesets in the changelog to evaluate. Specify as `--tag=myTag`. Positional format `<command> <tag>` deprecated in 4.4+.	Required
`cmdArgs: { url: "<string>" }`	The JDBC database connection URL. See Using JDBC URL in Liquibase.	Required
`cmdArgs: { change-exec-listener-class: "<string>" }`	Fully-qualified class which specifies a `ChangeExecListener`. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`cmdArgs: { change-exec-listener-properties-file: "<string>" }`	Path to a properties file for the `ChangeExecListener` class. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`cmdArgs: { context-filter: "<string>" }`	Specifies the changeset contexts to match. Contexts are tags you can add to changesets to control which changesets are executed in any particular migration run. Note: If you use Liquibase 4.23.0 or earlier, use the syntax `--contexts` instead of `--context-filter`.	Optional
`cmdArgs: { default-catalog-name: "<string>" }`	Name of the default catalog to use for the database connection	Optional
`cmdArgs: { default-schema-name: "<string>" }`	Name of the default schema to use for the database connection. If `defaultSchemaName` is set, then objects do not have to be fully qualified. This means you can refer to just `mytable` instead of `myschema.mytable`. Tip: In Liquibase v4.23.0+, camelCase for `defaultSchemaName` works successfully. If you are on an earlier version, camelCase may not work as expected. Note: The syntax `liquibase.command.defaultSchemaName` is valid for v4.19.0+. For prior versions, use `defaultSchemaName`.	Optional
`cmdArgs: { driver: "<string>" }`	The JDBC driver class	Optional
`cmdArgs: { driver-properties-file: "<string>" }`	The JDBC driver properties file	Optional
`cmdArgs: { label-filter: "<string>" }`	Specifies the changeset labels to match. Labels are tags you can add to changesets to control which changesets will be executed in any migration run.	Optional
`cmdArgs: { password: "<string>" }`	Password to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional
`cmdArgs: { rollback-script: "<string>" }`	The path to the script to use to perform the rollback. Only needed if the rollback is not already defined in the changelog, and if it is not a rollback statement that is automatically generated by Liquibase.	Optional
`cmdArgs: { tag-version: "<string>" }`	Tag version to use for multiple occurrences of a tag. Valid values are `NEWEST` and `OLDEST`. If set to `NEWEST`, Liquibase rolls back changes up to the most recent instance of the tag. Any older instances of the tag remain in the DATABASECHANGELOG table. If set to `OLDEST`, Liquibase rolls back changes up to the first instance of the tag. Default: `OLDEST`	Optional
`cmdArgs: { username: "<string>" }`	Username to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional

Attribute	Definition	Requirement
`liquibase.command.changelogFile: <string>` `liquibase.command.<cmdName>.changelogFile: <string>`	The root changelog	Required
`liquibase.command.tag: <string>` `liquibase.command.<cmdName>.tag: <string>`	The tag identifying which tagged changesets in the changelog to evaluate. Specify as `--tag=myTag`. Positional format `<command> <tag>` deprecated in 4.4+.	Required
`liquibase.command.url: <string>` `liquibase.command.<cmdName>.url: <string>`	The JDBC database connection URL. See Using JDBC URL in Liquibase.	Required
`liquibase.command.changeExecListenerClass: <string>` `liquibase.command.<cmdName>.changeExecListenerClass: <string>`	Fully-qualified class which specifies a `ChangeExecListener`. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`liquibase.command.changeExecListenerPropertiesFile: <string>` `liquibase.command.<cmdName>.changeExecListenerPropertiesFile: <string>`	Path to a properties file for the `ChangeExecListener` class. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`liquibase.command.contextFilter: <string>` `liquibase.command.<cmdName>.contextFilter: <string>`	Specifies the changeset contexts to match. Contexts are tags you can add to changesets to control which changesets are executed in any particular migration run. Note: If you use Liquibase 4.23.0 or earlier, use the syntax `--contexts` instead of `--context-filter`.	Optional
`liquibase.command.defaultCatalogName: <string>` `liquibase.command.<cmdName>.defaultCatalogName: <string>`	Name of the default catalog to use for the database connection	Optional
`liquibase.command.defaultSchemaName: <string>` `liquibase.command.<cmdName>.defaultSchemaName: <string>`	Name of the default schema to use for the database connection. If `defaultSchemaName` is set, then objects do not have to be fully qualified. This means you can refer to just `mytable` instead of `myschema.mytable`. Tip: In Liquibase v4.23.0+, camelCase for `defaultSchemaName` works successfully. If you are on an earlier version, camelCase may not work as expected. Note: The syntax `liquibase.command.defaultSchemaName` is valid for v4.19.0+. For prior versions, use `defaultSchemaName`.	Optional
`liquibase.command.driver: <string>` `liquibase.command.<cmdName>.driver: <string>`	The JDBC driver class	Optional
`liquibase.command.driverPropertiesFile: <string>` `liquibase.command.<cmdName>.driverPropertiesFile: <string>`	The JDBC driver properties file	Optional
`liquibase.command.labelFilter: <string>` `liquibase.command.<cmdName>.labelFilter: <string>`	Specifies the changeset labels to match. Labels are tags you can add to changesets to control which changesets will be executed in any migration run.	Optional
`liquibase.command.password: <string>` `liquibase.command.<cmdName>.password: <string>`	Password to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional
`liquibase.command.rollbackScript: <string>` `liquibase.command.<cmdName>.rollbackScript: <string>`	The path to the script to use to perform the rollback. Only needed if the rollback is not already defined in the changelog, and if it is not a rollback statement that is automatically generated by Liquibase.	Optional
`liquibase.command.tagVersion: <string>` `liquibase.command.<cmdName>.tagVersion: <string>`	Tag version to use for multiple occurrences of a tag. Valid values are `NEWEST` and `OLDEST`. If set to `NEWEST`, Liquibase rolls back changes up to the most recent instance of the tag. Any older instances of the tag remain in the DATABASECHANGELOG table. If set to `OLDEST`, Liquibase rolls back changes up to the first instance of the tag. Default: `OLDEST`	Optional
`liquibase.command.username: <string>` `liquibase.command.<cmdName>.username: <string>`	Username to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional

Attribute	Definition	Requirement
`JAVA_OPTS=-Dliquibase.command.changelogFile=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.changelogFile=<string>`	The root changelog	Required
`JAVA_OPTS=-Dliquibase.command.tag=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.tag=<string>`	The tag identifying which tagged changesets in the changelog to evaluate. Specify as `--tag=myTag`. Positional format `<command> <tag>` deprecated in 4.4+.	Required
`JAVA_OPTS=-Dliquibase.command.url=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.url=<string>`	The JDBC database connection URL. See Using JDBC URL in Liquibase.	Required
`JAVA_OPTS=-Dliquibase.command.changeExecListenerClass=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.changeExecListenerClass=<string>`	Fully-qualified class which specifies a `ChangeExecListener`. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`JAVA_OPTS=-Dliquibase.command.changeExecListenerPropertiesFile=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.changeExecListenerPropertiesFile=<string>`	Path to a properties file for the `ChangeExecListener` class. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`JAVA_OPTS=-Dliquibase.command.contextFilter=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.contextFilter=<string>`	Specifies the changeset contexts to match. Contexts are tags you can add to changesets to control which changesets are executed in any particular migration run. Note: If you use Liquibase 4.23.0 or earlier, use the syntax `--contexts` instead of `--context-filter`.	Optional
`JAVA_OPTS=-Dliquibase.command.defaultCatalogName=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.defaultCatalogName=<string>`	Name of the default catalog to use for the database connection	Optional
`JAVA_OPTS=-Dliquibase.command.defaultSchemaName=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.defaultSchemaName=<string>`	Name of the default schema to use for the database connection. If `defaultSchemaName` is set, then objects do not have to be fully qualified. This means you can refer to just `mytable` instead of `myschema.mytable`. Tip: In Liquibase v4.23.0+, camelCase for `defaultSchemaName` works successfully. If you are on an earlier version, camelCase may not work as expected. Note: The syntax `liquibase.command.defaultSchemaName` is valid for v4.19.0+. For prior versions, use `defaultSchemaName`.	Optional
`JAVA_OPTS=-Dliquibase.command.driver=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.driver=<string>`	The JDBC driver class	Optional
`JAVA_OPTS=-Dliquibase.command.driverPropertiesFile=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.driverPropertiesFile=<string>`	The JDBC driver properties file	Optional
`JAVA_OPTS=-Dliquibase.command.labelFilter=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.labelFilter=<string>`	Specifies the changeset labels to match. Labels are tags you can add to changesets to control which changesets will be executed in any migration run.	Optional
`JAVA_OPTS=-Dliquibase.command.password=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.password=<string>`	Password to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional
`JAVA_OPTS=-Dliquibase.command.rollbackScript=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.rollbackScript=<string>`	The path to the script to use to perform the rollback. Only needed if the rollback is not already defined in the changelog, and if it is not a rollback statement that is automatically generated by Liquibase.	Optional
`JAVA_OPTS=-Dliquibase.command.tagVersion=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.tagVersion=<string>`	Tag version to use for multiple occurrences of a tag. Valid values are `NEWEST` and `OLDEST`. If set to `NEWEST`, Liquibase rolls back changes up to the most recent instance of the tag. Any older instances of the tag remain in the DATABASECHANGELOG table. If set to `OLDEST`, Liquibase rolls back changes up to the first instance of the tag. Default: `OLDEST`	Optional
`JAVA_OPTS=-Dliquibase.command.username=<string>` `JAVA_OPTS=-Dliquibase.command.<cmdName>.username=<string>`	Username to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional

Attribute	Definition	Requirement
`LIQUIBASE_COMMAND_CHANGELOG_FILE=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_CHANGELOG_FILE=<string>`	The root changelog	Required
`LIQUIBASE_COMMAND_TAG=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_TAG=<string>`	The tag identifying which tagged changesets in the changelog to evaluate. Specify as `--tag=myTag`. Positional format `<command> <tag>` deprecated in 4.4+.	Required
`LIQUIBASE_COMMAND_URL=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_URL=<string>`	The JDBC database connection URL. See Using JDBC URL in Liquibase.	Required
`LIQUIBASE_COMMAND_CHANGE_EXEC_LISTENER_CLASS=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_CHANGE_EXEC_LISTENER_CLASS=<string>`	Fully-qualified class which specifies a `ChangeExecListener`. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`LIQUIBASE_COMMAND_CHANGE_EXEC_LISTENER_PROPERTIES_FILE=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_CHANGE_EXEC_LISTENER_PROPERTIES_FILE=<string>`	Path to a properties file for the `ChangeExecListener` class. For more information, see Implementing a Custom ChangeExecListener Class with Liquibase and ChangeExecListenerCommandStep.	Optional
`LIQUIBASE_COMMAND_CONTEXT_FILTER=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_CONTEXT_FILTER=<string>`	Specifies the changeset contexts to match. Contexts are tags you can add to changesets to control which changesets are executed in any particular migration run. Note: If you use Liquibase 4.23.0 or earlier, use the syntax `--contexts` instead of `--context-filter`.	Optional
`LIQUIBASE_COMMAND_DEFAULT_CATALOG_NAME=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_DEFAULT_CATALOG_NAME=<string>`	Name of the default catalog to use for the database connection	Optional
`LIQUIBASE_COMMAND_DEFAULT_SCHEMA_NAME=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_DEFAULT_SCHEMA_NAME=<string>`	Name of the default schema to use for the database connection. If `defaultSchemaName` is set, then objects do not have to be fully qualified. This means you can refer to just `mytable` instead of `myschema.mytable`. Tip: In Liquibase v4.23.0+, camelCase for `defaultSchemaName` works successfully. If you are on an earlier version, camelCase may not work as expected. Note: The syntax `liquibase.command.defaultSchemaName` is valid for v4.19.0+. For prior versions, use `defaultSchemaName`.	Optional
`LIQUIBASE_COMMAND_DRIVER=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_DRIVER=<string>`	The JDBC driver class	Optional
`LIQUIBASE_COMMAND_DRIVER_PROPERTIES_FILE=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_DRIVER_PROPERTIES_FILE=<string>`	The JDBC driver properties file	Optional
`LIQUIBASE_COMMAND_LABEL_FILTER=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_LABEL_FILTER=<string>`	Specifies the changeset labels to match. Labels are tags you can add to changesets to control which changesets will be executed in any migration run.	Optional
`LIQUIBASE_COMMAND_PASSWORD=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_PASSWORD=<string>`	Password to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional
`LIQUIBASE_COMMAND_ROLLBACK_SCRIPT=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_ROLLBACK_SCRIPT=<string>`	The path to the script to use to perform the rollback. Only needed if the rollback is not already defined in the changelog, and if it is not a rollback statement that is automatically generated by Liquibase.	Optional
`LIQUIBASE_COMMAND_TAG_VERSION=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_TAG_VERSION=<string>`	Tag version to use for multiple occurrences of a tag. Valid values are `NEWEST` and `OLDEST`. If set to `NEWEST`, Liquibase rolls back changes up to the most recent instance of the tag. Any older instances of the tag remain in the DATABASECHANGELOG table. If set to `OLDEST`, Liquibase rolls back changes up to the first instance of the tag. Default: `OLDEST`	Optional
`LIQUIBASE_COMMAND_USERNAME=<string>` `LIQUIBASE_COMMAND_<CMDNAME>_USERNAME=<string>`	Username to connect to the target database. Tip: It is a best practice to store sensitive data in a Secrets Management tool with Liquibase Pro.	Optional

Note: The username and password attributes are not required for connections and systems which use alternate means of authentication. Also, you can specify database credentials as part of the url attribute.

Additional rollback functionality

For more information, see Liquibase Rollback Workflow and Automatic and Custom Rollbacks.

Formatted SQL

Liquibase does not support an automatic rollback for formatted SQL changesets. Also, some Change Types have no corresponding rollback commands that can be automatically generated by Liquibase. In these cases, you should add custom rollback statements to the changesets if you want to use rollback commands. For example, in formatted SQL:

--changeset liquibaseuser:1
create table testTable ( id int primary key, name varchar(255) );
--rollback drop table testTable;
				
--changeset liquibaseuser:2
insert into testTable values ('1','The First', 'Country')
insert into testTable values ('2','The Second', 'Country2')
--rollback delete from testTable where id='1'
--rollback delete from testTable where id='2'

In Liquibase 4.26.0 and later, you can also specify rollback SQL for a changeset in a separate file using the --rollbackSqlFile statement:

--changeset liquibase-user:1
DROP PROCEDURE hello_world;
--rollbackSqlFile:release_1.0/rollback_45895.sql

For more information, see Example Changelogs: SQL Format.

Override default rollback commands

The <rollback> tag describes how to roll back a change using SQL statements, Change Types, or a reference to a previous changeset. You can use any Change Type in the <rollback> element, such as dropTable, sql, and sqlFile:

XML

<changeSet id="1" author="liquibaseuser">
    <createTable tableName="testTable">
        <column name="id" type="int"/>
    </createTable>
    <rollback>
        <dropTable tableName="testTable"/>
    </rollback>
</changeSet>

Alternatively, you can have raw SQL in the content part of the <rollback> element. For example:

<changeSet id="1" author="liquibaseuser">
    <createTable tableName="testTable">
        <column name="id" type="int"/>
    </createTable>
    <rollback>
        drop table testTable
    </rollback>
</changeSet>

Liquibase treats the raw SQL within <rollback> the same as in the <sql> Change Type, with stripComments set to true, splitStatements set to true, and endDelimiter set to ;. For more details, see the XML example from the sql documentation.

YAML

- changeSet:
    id: 1
    author: liquibaseuser
    changes:
      - createTable:
          tableName: testTable
          columns:
            - column:
                name: id
    rollback:
      - dropTable:
          tableName: testTable

JSON

{
  "changeSet": {
    "id": 1,
    "author": "liquibaseuser",
    "changes": [
      {
        "createTable": {
          "tableName": "testTable"
        }
      }
    ],
    "rollback": [
      {
        "dropTable": {
          "tableName": "testTable"
        }
      }
    ]
  }
}

Multiple rollbacks

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

XML

Change Type syntax:

<changeSet id="multiRollbackTest" author="liquibaseuser">
    <createTable tableName="multiRollback1">
        <column name="id" type="int"/>
    </createTable>
    <createTable tableName="multiRollback2">
        <column name="id" type="int"/>
    </createTable>
    <createTable tableName="multiRollback3">
        <column name="id" type="int"/>
    </createTable>
    <rollback>
        <dropTable tableName="multiRollback1"/>
        <dropTable tableName="multiRollback2"/>
    </rollback>
    <rollback>
      <dropTable tableName="multiRollback3"/>
    </rollback>
</changeSet>

Raw SQL:

<changeSet id="multiRollbackTest" author="liquibaseuser">
    <createTable tableName="multiRollback1">
        <column name="id" type="int"/>
    </createTable>
    <createTable tableName="multiRollback2">
        <column name="id" type="int"/>
    </createTable>
    <createTable tableName="multiRollback3">
        <column name="id" type="int"/>
    </createTable>
    <rollback>
        drop table multiRollback1;
        drop table multiRollback2;
    </rollback>
    <rollback>drop table multiRollback3</rollback>
</changeSet>

YAML

- changeSet:
    id: multiRollbackTest
    author: liquibaseuser
    changes:
      - createTable:
          tableName: multiRollback1
          columns:
            - column:
                name: id
      - createTable:
          tableName: multiRollback2
          columns:
            - column:
                name: id
      - createTable:
          tableName: multiRollback3
          columns:
            - column:
                name: id
    rollback:
      - dropTable:
          tableName: multiRollback1
      - dropTable:
          tableName: multiRollback2
    rollback:
      - dropTable:
          tableName: multiRollback3

JSON

{
  "changeSet": {
    "id": multiRollbackTest,
    "author": "liquibaseuser",
    "changes": [
      {
        "createTable": {
          "tableName": "multiRollback1",
          "columns": [
            {
              "column": {
                "name": "id"
              }
            }
          ]
        },
        "createTable": {
          "tableName": "multiRollback2"
          "columns": [
            {
              "column": {
                "name": "id"
              }
            }
          ]
        },
        "createTable": {
          "tableName": "multiRollback3"
          "columns": [
            {
              "column": {
                "name": "id"
              }
            }
          ]
        }
      }
    ],
    "rollback": [
      {
        "dropTable": {
          "tableName": "multiRollback1"
        },
        "dropTable": {
          "tableName": "multiRollback2"
        }
      }
    ],
    "rollback": [
      {
        "dropTable": {
          "tableName": "multiRollback3"
        }
      }
    ],
  }
}

Directly reference changeset

The following example shows how you can use a <rollback> tag to reference the changeset that originally created a statement. This example uses changeset 2 to implement rollback logic against changeset 1:

SQL

--changeset liquibaseuser:1
create table testTable ( id int primary key, name varchar(255) );

--changeset liquibaseuser:2
--rollback drop table testTable;
--rollback changesetId:1 changesetAuthor:liquibaseuser changesetPath:optional/path/to/myChangeLog.sql

XML

<changeSet id="1" author="liquibaseuser">
    <createTable tableName="testTable"/>
        <column name="id" type="varchar(255)"/>
    </createTable>
</changeSet>

<changeSet id="2" author="liquibaseuser">
    <dropTable tableName="testTable"/>
    <rollback changesetId="1" changesetAuthor="liquibaseuser" changesetPath="optional/path/to/myChangeLog.xml"/>
</changeSet>

YAML

- changeSet:
    id: 1
    author: liquibaseuser
    changes:
      - createTable:
          tableName: testTable
          columns:
            - column:
                name: id
- changeSet:
    id: 2
    author: liquibaseuser
    rollback:
      - dropTable:
          tableName: testTable
      changesetId: 1
      changesetAuthor: liquibaseuser
      changesetpath: optional/path/to/myChangeLog.yaml

JSON

{
  "changeSet": {
    "id": 1,
    "author": "liquibaseuser",
    "changes": [
      {
        "createTable": {
          "tableName": "testTable",
          "columns": [
            {
              "column": {
                "name": "id",
                "type": "varchar(255)"
              }
            }
          ]
        }
      }
    ]
{
  "changeSet": {
    "id": 2,
    "author": "liquibaseuser",
    "rollback": [
      {
        "dropTable": {
          "tableName": "testTable"
        }
      },
      "changesetId": "1",
      "changesetAuthor": "liquibaseuser",
      "changesetPath": "optional/path/to/myChangeLog.json"
    ]
  }
}

Empty rollback statements

If you do not want to revert a change in a rollback mode, use either the keyword empty or the keyword not required inside the rollback tag. In XML, YAML, and JSON changelogs, you can also use an empty string inside the rollback tag.

SQL

--changeset liquibaseuser:1
create table testTable ( id int primary key, name varchar(255) );
--rollback empty

XML

<changeSet id="3" author="liquibaseuser">
    <createTable tableName="testTable">
        <column name="id" type="int"/>
    </createTable>
    <rollback>empty</rollback>
</changeSet>

You can also use an empty string (<rollback></rollback>) or a self-closing-tag (<rollback/>).

YAML

- changeSet:
    id: 1
    author: liquibase
    changes:
      - createTable:
          tableName: testTable
          columns:
            - column:
                name: id
                type: int
    rollback: empty

You can also use an empty string (rollback: "").

JSON

{
  "changeSet": {
    "id": 1,
    "author": "example",
    "changes": [
      {
        "createTable": {
          "tableName": "testTable",
          "columns": [
            {
              "column": {
                "name": "id",
                "type": "int"
              }
            }
          ]
        }
      }
    ],
    "rollback": "empty"
  }
}

You can also use an empty string ("rollback": "").

Note: The empty and output Change Types support automatic rollbacks.

Output

When successful, the rollback command produces the following output:

Liquibase Version: 4.9.1
Rolling Back Changeset: example-changelog.sql::2::Amber.Williams
Rolling Back Changeset: example-changelog.sql::1::Amber.Williams
Liquibase command 'rollback' was executed successfully.
Liquibase: Rollback has been successful.

rollback

Uses

Impact

Syntax

Command parameters

Formatted SQL

Override default rollback commands

Multiple rollbacks

Directly reference changeset

Empty rollback statements

Related links

`rollback`