Use the include tag in the root changelog to reference other changelogs.


In Liquibase, you can break up your root changelog into more manageable pieces by creating multiple changelogs to separate your changesets in a way that makes sense for you. For example, you can separate changesets into their own files, according to features, releases, or other logical boundaries. Breaking up your changelogs can make it easier to find and manage complex database schema scripts.

The reason why you would use the include tag rather than using XML's built-in include functionality is that the parser sees just one large XML document. Liquibase needs to uniquely identify each changeset with an id, author, and file name.

For more guidance on structuring your changelogs, see Design Your Liquibase Project.

How to use the include tag

  1. Create a root changelog file, if you do not have one already. The root changelog file works as a configuration file that holds all the references to all your other changelogs.
  2. Note: Your root changelog must be an XML, YAML, or JSON file. Your root changelog cannot be a formatted SQL or formatted Mongo file.

  3. In your root changelog, add <include> tags with paths to your other changelogs.
  4. Note: The changelogs you include in your root changelog can be SQL, XML, YAML, or JSON files. If you use Liquibase MongoDB Pro 1.3.0+, you can also include formatted Mongo changelogs as JS files.

    	<include file="com/example/news/news.changelog.sql"/>
    	<include file="com/example/directory/directory.changelog.sql"/>
    - include:
        file: com/example/news/news.changelog.sql
    - include:
        file: com/example/directory/directory.changelog.sql
        "databaseChangeLog": [
                "include": {
                    "file": "com/example/news/news.changelog.sql"
                "include": {
                    "file": "com/example/directory/directory.changelog.sql"

How the include tag runs in a changelog

Liquibase runs all included changelogs in the order they are found. Make sure that the included changelogs are completely independent or that any required changelogs are run first.

In the root changelog examples above, the root changelog first includes the changes in com/example/news/news.changelog.sql and then includes the changes in com/example/directory/directory.changelog.sql.

You should define Preconditions in your reference changelogs. Liquibase will evaluate them before running any changesets.

Double inclusion of changelogs

Liquibase does not check for the double inclusion of changelogs in your root file. However, if you include a changelog twice, Liquibase recognizes that the changesets have already been run and will not run them again, even if you use a <runAlways> tag.

Infinite loops in changelogs

Liquibase does not check for looping changelogs in your root file. However, if you create a changelog loop like the following, you will get an infinite loop which will prevent the operation from completing:

Example: root.changelog.xml includes news.changelog.xml which includes root.changelog.xml.

Make sure to avoid infinite loops when referencing changelogs. If you create an infinite loop, Liquibase will display the following error, and will continue to loop until the process runs out of memory:

Unexpected error running Liquibase: Unknown reason

Available attributes

Attribute Description Requirement
file Name of the file you want to import required. Required

Appends a context (using an AND statement) to all contained changesets.

Note: If you use Liquibase 4.23.0 or earlier, use the syntax contextFilter instead of context.

Example: <include file="dbchangelog_roll-forward.xml" context="DEV"/>


Controls what happens if the file listed does not exist. If set to true, the update fails. Default: true.

ignore Tell Liquibase to treat changesets in the included file as if it does not exist. Liquibase 3.7.0+. Default: false. Optional

Appends a label (using an AND statement) to all contained changesets.

Example: <include file="dbchangelog_roll-forward.xml" labels="rollback_version1"/>


Specifies whether the file path is relative to the changelog file rather than looked up in the search path. Default: false.


Related links