generate-changelog

Last updated: March 24, 2026

The generate-changelog command creates a changelog file that has a sequence of changesets which describe how to re-create the current state of the database.

Uses

The generate-changelog command is typically used when you want to capture the current state of a database, then apply those changes to any number of databases. This is typically only done when a project has an existing database, but hasn't used Liquibase before. See How to set up Liquibase with an Existing Project and Multiple Environments for more details.

Note: When using the update command to apply the changes in the changelog, Liquibase will not create a new database or schema. You must create them before applying the changelog to it.

Run the generate-changelog command

In this example, our sample database has the following content:

command-generate-changelog-initial-database

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.

* --include-tablespace only captures the tablespace if it was specified in the create table statement.

Output changelogs

The generate-changelog command generates a changelog that contains all your objects (represented as changesets) and places the file in the same directory where the command was ran.

The extension you provide determines the format of the changelog, so if you specify the filename as changelog.xml, you will get an XML formatted changelog. However, if you specify the filename as changelog.yaml, changelog.json, or changelog.sql, you will get changelogs formatted in YAML, JSON, or SQL, respectively.

Note: By default, Liquibase does not split statements for formatted SQL changelogs because splitStatements is set to false in the changelog. If the generatedSQL has multiple SQL statements, then Liquibase adds splitStatements:true to the changelog. Learn more about split statements here: sql

Default diff types

loading

loading

loading

loading

Specific diff types

loading

loading

loading

loading

Parameters

Global parameters

Attribute

Definition

Requirement

--license-key=<string>

Your Liquibase Pro license key

Required

Command parameters

Attribute

Definition

Requirement

--url=<string>

The JDBC database connection URL.

Required

--author=<string>

Specifies the author for changesets in the generated changelog.

Optional

--changelog-file=<string>

Changelog file to write results

Optional

--context-filter=<string>

Specifies the context filter to generate and apply to all changesets in your changelog. Useful to set many contexts quickly. Similar to the set-contexts command. Available in Liquibase 4.24.0 and later.

Contexts are tags you can add to changesets to control which changesets will be executed in any particular migration run.

After generating changesets with contexts, to deploy specific changes according to these contexts, you must run a command that specifies a context filter. For example, update --context-filter=<xyz>.

Optional

--data-output-directory=<string>

Specifies a directory to send the loadData output to a CSV file which is generated by running the diff-changelog or generate-changelog command.

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.

Note: In the properties file and JAVA_OPTS only: in 4.18.0 and earlier, specify this parameter using the syntax defaultSchemaName. In 4.19.0 and later, use the syntax liquibase.command.defaultSchemaName.

Note: In Liquibase 4.12.0 and later, you can use mixed-case schema names if you set --preserve-schema-case to true. However, in Liquibase 4.12.0–4.22.0, the Liquibase validator still throws a DatabaseException error if you specify a mixed-case value of defaultSchemaName. In 4.23.0 and later, the Liquibase validator accepts any casing.

Optional

--diff-types=<string>

Specifies the types of objects to compare. Specify multiple values as a comma-separated list (without spaces). Valid values are: catalogs, checkconstraints, columns, data, databasepackage, databasepackagebody, foreignkeys, functions, indexes, primarykeys, sequences, storedprocedures, tables, triggers, uniqueconstraints, views.

If null, default types are columns, foreignkeys, indexes, primarykeys, tables, uniqueconstraints, views.

Liquibase Secure 5.1.0+. Snowflake accepted values are: catalogs, checkconstraints, data, databasepackage, databasepackagebody, FileFormat, foreignkeys, functions, indexes, primarykeys, sequences, SnowflakeDynamicTable, SnowflakeDynamicTableColumn, SnowflakeStage, SnowflakeStandardTable, SnowflakeStandardTableColumn, SnowflakeView, SnowflakeViewColumn, storedprocedures, and triggers.

Note: For Snowflake, unique constraints are not snapshotted as standalone objects. Instead, uniqueness is captured as the isUnique attribute on the column definition.

Snowflake view and table support has been enhanced with four Snowflake-specific view and table objects: Snowflake standard views, Snowflake materialized views, Snowflake standard tables, and Snowflake dynamic tables. The generic Liquibase VIEW and TABLE objects are supported for backward compatibility in CRUD operations only and do not support database inspection. For full Snowflake functionality, use the Snowflake standard view, Snowflake standard table, and Snowflake dynamic table objects. The Snowflake materialized view objects support CRUD operations.

Note: The diff types checkconstraints, databasepackage, databasepackagebody, functions, storedprocedures, triggers, and Snowflake-specific values require Liquibase Secure.

Optional

--driver=<string>

The JDBC driver class

Optional

--driver-properties-file=<string>

The JDBC driver properties file

Optional

--exclude-objects=<string>

Objects to exclude from diff

Optional

--ignore-missing-references=[true|false]

Controls behavior when snapshots reference objects from schemas not included in the snapshot (like cross-schema triggers or foreign keys) Default: false

Optional

--include-catalog=<true|false>

If true, the catalog will be included in generated changesets. Default: false

Optional

--include-objects=<string>

Objects to include in diff

Optional

--include-schema=<true|false>

If true, the schema will be included in generated changesets. Default: false.

When specifying multiple schemas see Diff multiple schemas in Liquibase for file path considerations when same-named objects exist across schemas.

Optional

--include-tablespace=<true|false>

Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false.

Optional *

--label-filter=<string>

Specifies the label filter to generate and apply to all changesets in your changelog. Useful to set many labels quickly. Similar to the set-labels command. Available in Liquibase 4.24.0 and later.

Labels are tags you can add to changesets to control which changeset will be executed in any migration run.

After generating changesets with labels, to deploy specific changes according to these labels, you must run a command that specifies a label filter. For example, update --label-filter=<xyz>.

Optional

--object-changelogs=<string>

Generates a separate changelog for each object. Valid values: all (generate changelogs for all object types), table, view, dml, triggers, functions, sequences, storedprocedures, packages, packagebodies, checkconstraints, indexes, foreignkeys, primarykeys, uniqueconstraints, and none. Default: none.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

--output-schemas=<string>

Lets you replace the schemas in the output changelog. This is a CSV list. The parameter size must match --schemas. If you have three items names in --schemas, you must also have three items in --output-schemas.

Example: liquibase generate-changelog --schemas=a,b,c --output-schemas=d,e,f

Optional

--overwrite-output-file=<true|false>

Determines whether generate-changelog can overwrite an existing changelog, including one specified in --changelog-file. Default: false.

Optional

--password=<string>

Password to connect to the target database.

Optional

--replace-if-exists-types=<string>

Specify Change Types you want to target. Liquibase sets replaceIfExists="true" on these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

--run-on-change-types=<string>

Specify Change Types you want to target. Liquibase sets runOnChange="true" on changesets containing solely these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

--schemas=<string>

Specifies database schemas you want to include

Optional

--skip-object-sorting=<true|false>

When true, skips Liquibase's dependency-based object ordering. By default, Liquibase 5.2 and later automatically orders changesets so they can be deployed without manual reordering.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

--username=<string>

Username to connect to the target database.

Optional

Global parameters

Attribute

Definition

Requirement

globalArgs: { license-key: "<string>" }

Your Liquibase Pro license key

Required

Command parameters

Attribute

Definition

Requirement

cmdArgs: { url: "<string>" }

The JDBC database connection URL.

Required

cmdArgs: { author: "<string>" }

Specifies the author for changesets in the generated changelog.

Optional

cmdArgs: { changelog-file: "<string>" }

Changelog file to write results

Optional

cmdArgs: { context-filter: "<string>" }

Specifies the context filter to generate and apply to all changesets in your changelog. Useful to set many contexts quickly. Similar to the set-contexts command. Available in Liquibase 4.24.0 and later.

Contexts are tags you can add to changesets to control which changesets will be executed in any particular migration run.

After generating changesets with contexts, to deploy specific changes according to these contexts, you must run a command that specifies a context filter. For example, update --context-filter=<xyz>.

Optional

cmdArgs: { data-output-directory: "<string>" }

Specifies a directory to send the loadData output to a CSV file which is generated by running the diff-changelog or generate-changelog command.

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.

Note: In the properties file and JAVA_OPTS only: in 4.18.0 and earlier, specify this parameter using the syntax defaultSchemaName. In 4.19.0 and later, use the syntax liquibase.command.defaultSchemaName.

Note: In Liquibase 4.12.0 and later, you can use mixed-case schema names if you set --preserve-schema-case to true. However, in Liquibase 4.12.0–4.22.0, the Liquibase validator still throws a DatabaseException error if you specify a mixed-case value of defaultSchemaName. In 4.23.0 and later, the Liquibase validator accepts any casing.

Optional

cmdArgs: { diff-types: "<string>" }

Specifies the types of objects to compare. Specify multiple values as a comma-separated list (without spaces). Valid values are: catalogs, checkconstraints, columns, data, databasepackage, databasepackagebody, foreignkeys, functions, indexes, primarykeys, sequences, storedprocedures, tables, triggers, uniqueconstraints, views.

If null, default types are columns, foreignkeys, indexes, primarykeys, tables, uniqueconstraints, views.

Liquibase Secure 5.1.0+. Snowflake accepted values are: catalogs, checkconstraints, data, databasepackage, databasepackagebody, FileFormat, foreignkeys, functions, indexes, primarykeys, sequences, SnowflakeDynamicTable, SnowflakeDynamicTableColumn, SnowflakeStage, SnowflakeStandardTable, SnowflakeStandardTableColumn, SnowflakeView, SnowflakeViewColumn, storedprocedures, and triggers.

Note: For Snowflake, unique constraints are not snapshotted as standalone objects. Instead, uniqueness is captured as the isUnique attribute on the column definition.

Snowflake view and table support has been enhanced with four Snowflake-specific view and table objects: Snowflake standard views, Snowflake materialized views, Snowflake standard tables, and Snowflake dynamic tables. The generic Liquibase VIEW and TABLE objects are supported for backward compatibility in CRUD operations only and do not support database inspection. For full Snowflake functionality, use the Snowflake standard view, Snowflake standard table, and Snowflake dynamic table objects. The Snowflake materialized view objects support CRUD operations.

Note: The diff types checkconstraints, databasepackage, databasepackagebody, functions, storedprocedures, triggers, and Snowflake-specific values require Liquibase Secure.

Optional

cmdArgs: { driver: "<string>" }

The JDBC driver class

Optional

cmdArgs: { driver-properties-file: "<string>" }

The JDBC driver properties file

Optional

cmdArgs: { exclude-objects: "<string>" }

Objects to exclude from diff

Optional

cmdArgs: { ignore-missing-references: "<true|false>" }

Controls behavior when snapshots reference objects from schemas not included in the snapshot (like cross-schema triggers or foreign keys) Default: false

Optional

cmdArgs: { include-catalog: "<true|false>" }

If true, the catalog will be included in generated changesets. Default: false

Optional

cmdArgs: { include-objects: "<string>" }

Objects to include in diff

Optional

cmdArgs: { include-schema: "<true|false>" }

If true, the schema will be included in generated changesets. Default: false.

When specifying multiple schemas see Diff multiple schemas in Liquibase for file path considerations when same-named objects exist across schemas.

Optional

cmdArgs: { include-tablespace: "<true|false>" }

Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false.

Optional *

cmdArgs: { label-filter: "<string>" }

Specifies the label filter to generate and apply to all changesets in your changelog. Useful to set many labels quickly. Similar to the set-labels command. Available in Liquibase 4.24.0 and later.

Labels are tags you can add to changesets to control which changeset will be executed in any migration run.

After generating changesets with labels, to deploy specific changes according to these labels, you must run a command that specifies a label filter. For example, update --label-filter=<xyz>.

Optional

cmdArgs: { object-changelogs: "<string>" }

Generates a separate changelog for each object. Valid values: all (generate changelogs for all object types), table, view, dml, triggers, functions, sequences, storedprocedures, packages, packagebodies, checkconstraints, indexes, foreignkeys, primarykeys, uniqueconstraints, and none. Default: none.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

cmdArgs: { output-schemas: "<string>" }

Lets you replace the schemas in the output changelog. This is a CSV list. The parameter size must match --schemas. If you have three items names in --schemas, you must also have three items in --output-schemas.

Example: liquibase generate-changelog --schemas=a,b,c --output-schemas=d,e,f

Optional

cmdArgs: { overwrite-output-file: "<true|false>" }

Determines whether generate-changelog can overwrite an existing changelog, including one specified in --changelog-file. Default: false.

Optional

cmdArgs: { password: "<string>" }

Password to connect to the target database.

Optional

cmdArgs: { replace-if-exists-types: "<string>" }

Specify Change Types you want to target. Liquibase sets replaceIfExists="true" on these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

cmdArgs: { run-on-change-types: "<string>" }

Specify Change Types you want to target. Liquibase sets runOnChange="true" on changesets containing solely these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

cmdArgs: { schemas: "<string>" }

Specifies database schemas you want to include

Optional

cmdArgs: { skip-object-sorting: "<true|false>" }

When true, skips Liquibase's dependency-based object ordering. By default, Liquibase 5.2 and later automatically orders changesets so they can be deployed without manual reordering.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

cmdArgs: { username: "<string>" }

Username to connect to the target database.

Optional

Global parameters

Attribute

Definition

Requirement

liquibase.licenseKey: <string>

Your Liquibase Pro license key

Required

Command parameters

Attribute

Definition

Requirement

liquibase.command.url: <string>

liquibase.command.generateChangelog.url: <string>

The JDBC database connection URL.

Required

liquibase.command.author: <string>

liquibase.command.generateChangelog.author: <string>

Specifies the author for changesets in the generated changelog.

Optional

liquibase.command.changelogFile: <string>

liquibase.command.generateChangelog.changelogFile: <string>

Changelog file to write results

Optional

liquibase.command.contextFilter: <string>

liquibase.command.generateChangelog.contextFilter: <string>

Specifies the context filter to generate and apply to all changesets in your changelog. Useful to set many contexts quickly. Similar to the set-contexts command. Available in Liquibase 4.24.0 and later.

Contexts are tags you can add to changesets to control which changesets will be executed in any particular migration run.

After generating changesets with contexts, to deploy specific changes according to these contexts, you must run a command that specifies a context filter. For example, update --context-filter=<xyz>.

Optional

liquibase.command.dataOutputDirectory: <string>

liquibase.command.generateChangelog.dataOutputDirectory: <string>

Specifies a directory to send the loadData output to a CSV file which is generated by running the diff-changelog or generate-changelog command.

Optional

liquibase.command.defaultCatalogName: <string>

liquibase.command.generateChangelog.defaultCatalogName: <string>

Name of the default catalog to use for the database connection

Optional

liquibase.command.defaultSchemaName: <string>

liquibase.command.generateChangelog.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.

Note: In the properties file and JAVA_OPTS only: in 4.18.0 and earlier, specify this parameter using the syntax defaultSchemaName. In 4.19.0 and later, use the syntax liquibase.command.defaultSchemaName.

Note: In Liquibase 4.12.0 and later, you can use mixed-case schema names if you set --preserve-schema-case to true. However, in Liquibase 4.12.0–4.22.0, the Liquibase validator still throws a DatabaseException error if you specify a mixed-case value of defaultSchemaName. In 4.23.0 and later, the Liquibase validator accepts any casing.

Optional

liquibase.command.diffTypes: <string>

liquibase.command.generateChangelog.diffTypes: <string>

Specifies the types of objects to compare. Specify multiple values as a comma-separated list (without spaces). Valid values are: catalogs, checkconstraints, columns, data, databasepackage, databasepackagebody, foreignkeys, functions, indexes, primarykeys, sequences, storedprocedures, tables, triggers, uniqueconstraints, views.

If null, default types are columns, foreignkeys, indexes, primarykeys, tables, uniqueconstraints, views.

Liquibase Secure 5.1.0+. Snowflake accepted values are: catalogs, checkconstraints, data, databasepackage, databasepackagebody, FileFormat, foreignkeys, functions, indexes, primarykeys, sequences, SnowflakeDynamicTable, SnowflakeDynamicTableColumn, SnowflakeStage, SnowflakeStandardTable, SnowflakeStandardTableColumn, SnowflakeView, SnowflakeViewColumn, storedprocedures, and triggers. Note: For Snowflake, unique constraints are not snapshotted as standalone objects. Instead, uniqueness is captured as the isUnique attribute on the column definition.

Snowflake view and table support has been enhanced with four Snowflake-specific view and table objects: Snowflake standard views, Snowflake materialized views, Snowflake standard tables, and Snowflake dynamic tables. The generic Liquibase VIEW and TABLE objects are supported for backward compatibility in CRUD operations only and do not support database inspection. For full Snowflake functionality, use the Snowflake standard view, Snowflake standard table, and Snowflake dynamic table objects. The Snowflake materialized view objects support CRUD operations.

Note: The diff types checkconstraints, databasepackage, databasepackagebody, functions, storedprocedures, triggers, and Snowflake-specific values require Liquibase Secure.

Optional

liquibase.command.driver: <string>

liquibase.command.generateChangelog.driver: <string>

The JDBC driver class

Optional

liquibase.command.driverPropertiesFile: <string>

liquibase.command.generateChangelog.driverPropertiesFile: <string>

The JDBC driver properties file

Optional

liquibase.command.excludeObjects: <string>

liquibase.command.generateChangelog.excludeObjects: <string>

Objects to exclude from diff

Optional

liquibase.command.ignoreMissingReferences=[true|false] or liquibase.command.diff.ignoreMissingReferences=[true|false]

Controls behavior when snapshots reference objects from schemas not included in the snapshot (like cross-schema triggers or foreign keys) Default: false

Optional

liquibase.command.includeCatalog: <true|false>

liquibase.command.generateChangelog.includeCatalog: <true|false>

If true, the catalog will be included in generated changesets. Default: false

Optional

liquibase.command.includeObjects: <string>

liquibase.command.generateChangelog.includeObjects: <string>

Objects to include in diff

Optional

liquibase.command.includeSchema: <true|false>

liquibase.command.generateChangelog.includeSchema: <true|false>

If true, the schema will be included in generated changesets. Default: false.

When specifying multiple schemas see Diff multiple schemas in Liquibase for file path considerations when same-named objects exist across schemas.

Optional

liquibase.command.includeTablespace: <true|false>

liquibase.command.generateChangelog.includeTablespace: <true|false>

Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false.

Optional *

liquibase.command.labelFilter: <string>

liquibase.command.generateChangelog.labelFilter: <string>

Specifies the label filter to generate and apply to all changesets in your changelog. Useful to set many labels quickly. Similar to the set-labels command. Available in Liquibase 4.24.0 and later.

Labels are tags you can add to changesets to control which changeset will be executed in any migration run.

After generating changesets with labels, to deploy specific changes according to these labels, you must run a command that specifies a label filter. For example, update --label-filter=<xyz>.

Optional

liquibase.command.objectChangelogs: <string>

liquibase.command.generateChangelog.objectChangelogs: <string>

Generates a separate changelog for each object. Valid values: all (generate changelogs for all object types), table, view, dml, triggers, functions, sequences, storedprocedures, packages, packagebodies, checkconstraints, indexes, foreignkeys, primarykeys, uniqueconstraints, and none. Default: none.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

liquibase.command.outputSchemas: <string>

liquibase.command.generateChangelog.outputSchemas: <string>

Lets you replace the schemas in the output changelog. This is a CSV list. The parameter size must match --schemas. If you have three items names in --schemas, you must also have three items in --output-schemas.

Example: liquibase generate-changelog --schemas=a,b,c --output-schemas=d,e,f

Optional

liquibase.command.overwriteOutputFile: <true|false>

liquibase.command.generateChangelog.overwriteOutputFile: <true|false>

Determines whether generate-changelog can overwrite an existing changelog, including one specified in --changelog-file. Default: false.

Optional

liquibase.command.password: <string>

liquibase.command.generateChangelog.password: <string>

Password to connect to the target database.

Optional

liquibase.command.replaceIfExistsTypes: <string>

liquibase.command.generateChangelog.replaceIfExistsTypes: <string>

Specify Change Types you want to target. Liquibase sets replaceIfExists="true" on these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

liquibase.command.runOnChangeTypes: <string>

liquibase.command.generateChangelog.runOnChangeTypes: <string>

Specify Change Types you want to target. Liquibase sets runOnChange="true" on changesets containing solely these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

liquibase.command.schemas: <string>

liquibase.command.generateChangelog.schemas: <string>

Specifies database schemas you want to include

Optional

liquibase.command.skipObjectSorting: <true|false>

liquibase.command.generateChangelog.skipObjectSorting: <true|false>

When true, skips Liquibase's dependency-based object ordering. By default, Liquibase 5.2 and later automatically orders changesets so they can be deployed without manual reordering.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

liquibase.command.username: <string>

liquibase.command.generateChangelog.username: <string>

Username to connect to the target database.

Optional

Global parameters

Attribute

Definition

Requirement

JAVA_OPTS=-Dliquibase.licenseKey=<string>

Your Liquibase Pro license key

Required

Command parameters

Attribute

Definition

Requirement

JAVA_OPTS=-Dliquibase.command.url=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.url=<string>

The JDBC database connection URL.

Required

JAVA_OPTS=-Dliquibase.command.author=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.author=<string>

Specifies the author for changesets in the generated changelog.

Optional

JAVA_OPTS=-Dliquibase.command.changelogFile=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.changelogFile=<string>

Changelog file to write results

Optional

JAVA_OPTS=-Dliquibase.command.contextFilter=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.contextFilter=<string>

Specifies the context filter to generate and apply to all changesets in your changelog. Useful to set many contexts quickly. Similar to the set-contexts command. Available in Liquibase 4.24.0 and later.

Contexts are tags you can add to changesets to control which changesets will be executed in any particular migration run.

After generating changesets with contexts, to deploy specific changes according to these contexts, you must run a command that specifies a context filter. For example, update --context-filter=<xyz>.

Optional

JAVA_OPTS=-Dliquibase.command.dataOutputDirectory=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.dataOutputDirectory=<string>

Specifies a directory to send the loadData output to a CSV file which is generated by running the diff-changelog or generate-changelog command.

Optional

JAVA_OPTS=-Dliquibase.command.defaultCatalogName=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.defaultCatalogName=<string>

Name of the default catalog to use for the database connection

Optional

JAVA_OPTS=-Dliquibase.command.defaultSchemaName=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.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.

Note: In the properties file and JAVA_OPTS only: in 4.18.0 and earlier, specify this parameter using the syntax defaultSchemaName. In 4.19.0 and later, use the syntax liquibase.command.defaultSchemaName.

Note: In Liquibase 4.12.0 and later, you can use mixed-case schema names if you set --preserve-schema-case to true. However, in Liquibase 4.12.0–4.22.0, the Liquibase validator still throws a DatabaseException error if you specify a mixed-case value of defaultSchemaName. In 4.23.0 and later, the Liquibase validator accepts any casing.

Optional

JAVA_OPTS=-Dliquibase.command.diffTypes=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.diffTypes=<string>

Specifies the types of objects to compare. Specify multiple values as a comma-separated list (without spaces). Valid values are: catalogs, checkconstraints, columns, data, databasepackage, databasepackagebody, foreignkeys, functions, indexes, primarykeys, sequences, storedprocedures, tables, triggers, uniqueconstraints, views.

If null, default types are columns, foreignkeys, indexes, primarykeys, tables, uniqueconstraints, views.

Liquibase Secure 5.1.0+. Snowflake accepted values are: catalogs, checkconstraints, data, databasepackage, databasepackagebody, FileFormat, foreignkeys, functions, indexes, primarykeys, sequences, SnowflakeDynamicTable, SnowflakeDynamicTableColumn, SnowflakeStage, SnowflakeStandardTable, SnowflakeStandardTableColumn, SnowflakeView, SnowflakeViewColumn, storedprocedures, and triggers. Note: For Snowflake, unique constraints are not snapshotted as standalone objects. Instead, uniqueness is captured as the isUnique attribute on the column definition.

Snowflake view and table support has been enhanced with four Snowflake-specific view and table objects: Snowflake standard views, Snowflake materialized views, Snowflake standard tables, and Snowflake dynamic tables. The generic Liquibase VIEW and TABLE objects are supported for backward compatibility in CRUD operations only and do not support database inspection. For full Snowflake functionality, use the Snowflake standard view, Snowflake standard table, and Snowflake dynamic table objects. The Snowflake materialized view objects support CRUD operations.

Note: The diff types checkconstraints, databasepackage, databasepackagebody, functions, storedprocedures, triggers, and Snowflake-specific values require Liquibase Secure.

Optional

JAVA_OPTS=-Dliquibase.command.driver=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.driver=<string>

The JDBC driver class

Optional

JAVA_OPTS=-Dliquibase.command.driverPropertiesFile=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.driverPropertiesFile=<string>

The JDBC driver properties file

Optional

JAVA_OPTS=-Dliquibase.command.excludeObjects=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.excludeObjects=<string>

Objects to exclude from diff

Optional

Unix Dliquibase.ignoreMissingReferences=[true|false] Windows D"liquibase.ignoreMissingReferences"=[true|false]

Controls behavior when snapshots reference objects from schemas not included in the snapshot (like cross-schema triggers or foreign keys) Default: false

Optional

JAVA_OPTS=-Dliquibase.command.includeCatalog=<true|false>

JAVA_OPTS=-Dliquibase.command.generateChangelog.includeCatalog=<true|false>

If true, the catalog will be included in generated changesets. Default: false

Optional

JAVA_OPTS=-Dliquibase.command.includeObjects=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.includeObjects=<string>

Objects to include in diff

Optional

JAVA_OPTS=-Dliquibase.command.includeSchema=<true|false>

JAVA_OPTS=-Dliquibase.command.generateChangelog.includeSchema=<true|false>

If true, the schema will be included in generated changesets. Default: false.

When specifying multiple schemas see Diff multiple schemas in Liquibase for file path considerations when same-named objects exist across schemas.

Optional

JAVA_OPTS=-Dliquibase.command.includeTablespace=<true|false>

JAVA_OPTS=-Dliquibase.command.generateChangelog.includeTablespace=<true|false>

Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false.

Optional *

JAVA_OPTS=-Dliquibase.command.labelFilter=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.labelFilter=<string>

Specifies the label filter to generate and apply to all changesets in your changelog. Useful to set many labels quickly. Similar to the set-labels command. Available in Liquibase 4.24.0 and later.

Labels are tags you can add to changesets to control which changeset will be executed in any migration run.

After generating changesets with labels, to deploy specific changes according to these labels, you must run a command that specifies a label filter. For example, update --label-filter=<xyz>.

Optional

JAVA_OPTS=-Dliquibase.command.objectChangelogs=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.objectChangelogs=<string>

Generates a separate changelog for each object. Valid values: all (generate changelogs for all object types), table, view, dml, triggers, functions, sequences, storedprocedures, packages, packagebodies, checkconstraints, indexes, foreignkeys, primarykeys, uniqueconstraints, and none. Default: none.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

JAVA_OPTS=-Dliquibase.command.outputSchemas=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.outputSchemas=<string>

Lets you replace the schemas in the output changelog. This is a CSV list. The parameter size must match --schemas. If you have three items names in --schemas, you must also have three items in --output-schemas.

Example: liquibase generate-changelog --schemas=a,b,c --output-schemas=d,e,f

Optional

JAVA_OPTS=-Dliquibase.command.overwriteOutputFile=<true|false>

JAVA_OPTS=-Dliquibase.command.generateChangelog.overwriteOutputFile=<true|false>

Determines whether generate-changelog can overwrite an existing changelog, including one specified in --changelog-file. Default: false.

Optional

JAVA_OPTS=-Dliquibase.command.password=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.password=<string>

Password to connect to the target database.

Optional

JAVA_OPTS=-Dliquibase.command.replaceIfExistsTypes=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.replaceIfExistsTypes=<string>

Specify Change Types you want to target. Liquibase sets replaceIfExists="true" on these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

JAVA_OPTS=-Dliquibase.command.runOnChangeTypes=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.runOnChangeTypes=<string>

Specify Change Types you want to target. Liquibase sets runOnChange="true" on changesets containing solely these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

JAVA_OPTS=-Dliquibase.command.schemas=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.schemas=<string>

Specifies database schemas you want to include

Optional

JAVA_OPTS=-Dliquibase.command.skipObjectSorting=<true|false>

JAVA_OPTS=-Dliquibase.command.generateChangelog.skipObjectSorting=<true|false>

When true, skips Liquibase's dependency-based object ordering. By default, Liquibase 5.2 and later automatically orders changesets so they can be deployed without manual reordering.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

Unix:

JAVA_OPTS=-Doracle.jdbc.useFetchSizeWithLongColumn=<true|false>

Windows:

JAVA_OPTS=-D"Doracle.jdbc.useFetchSizeWithLongColumn"=<true|false>

Liquibase Secure 5.1+ This is a JVM system property that controls how the Oracle JDBC driver handles fetch sizes when querying tables containing LONG or LONG RAW columns. It is available in Liquibase 5.1.0 and later. The default value istrue, which enables optimized batch fetching for improved performance on Oracle databases. You can set this property tofalseif you need more controlled memory usage when working with large LONG or LONG RAW data types. Uses

You might want to set this property tofalsein scenarios where: Memory constraints Your environment has limited memory resources and you need more controlled fetching to prevent the driver from eagerly loading large amounts of data Large LONG/LONG RAW data You're working with very large LONG or LONG RAW data types and need to manage how data is fetched to avoid memory issues Resource management Your application requires fine-grained control over memory usage when processing large-scale data

Optional

JAVA_OPTS=-Dliquibase.command.username=<string>

JAVA_OPTS=-Dliquibase.command.generateChangelog.username=<string>

Username to connect to the target database.

Optional

Global parameters

Attribute

Definition

Requirement

LIQUIBASE_LICENSE_KEY=<string>

Your Liquibase Pro license key

Required

Command parameters

Attribute

Definition

Requirement

LIQUIBASE_COMMAND_URL=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_URL=<string>

The JDBC database connection URL.

Required

LIQUIBASE_COMMAND_AUTHOR=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_AUTHOR=<string>

Specifies the author for changesets in the generated changelog.

Optional

LIQUIBASE_COMMAND_CHANGELOG_FILE=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_CHANGELOG_FILE=<string>

Changelog file to write results

Optional

LIQUIBASE_COMMAND_CONTEXT_FILTER=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_CONTEXT_FILTER=<string>

Specifies the context filter to generate and apply to all changesets in your changelog. Useful to set many contexts quickly. Similar to the set-contexts command. Available in Liquibase 4.24.0 and later.

Contexts are tags you can add to changesets to control which changesets will be executed in any particular migration run.

After generating changesets with contexts, to deploy specific changes according to these contexts, you must run a command that specifies a context filter. For example, update --context-filter=<xyz>.

Optional

LIQUIBASE_COMMAND_DATA_OUTPUT_DIRECTORY=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_DATA_OUTPUT_DIRECTORY=<string>

Specifies a directory to send the loadData output to a CSV file which is generated by running the diff-changelog or generate-changelog command.

Optional

LIQUIBASE_COMMAND_DEFAULT_CATALOG_NAME=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_DEFAULT_CATALOG_NAME=<string>

Name of the default catalog to use for the database connection

Optional

LIQUIBASE_COMMAND_DEFAULT_SCHEMA_NAME=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_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.

Note: In the properties file and JAVA_OPTS only: in 4.18.0 and earlier, specify this parameter using the syntax defaultSchemaName. In 4.19.0 and later, use the syntax liquibase.command.defaultSchemaName.

Note: In Liquibase 4.12.0 and later, you can use mixed-case schema names if you set --preserve-schema-case to true. However, in Liquibase 4.12.0–4.22.0, the Liquibase validator still throws a DatabaseException error if you specify a mixed-case value of defaultSchemaName. In 4.23.0 and later, the Liquibase validator accepts any casing.

Optional

LIQUIBASE_COMMAND_DIFF_TYPES=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_DIFF_TYPES=<string>

Specifies the types of objects to compare. Specify multiple values as a comma-separated list (without spaces). Valid values are: catalogs, checkconstraints, columns, data, databasepackage, databasepackagebody, foreignkeys, functions, indexes, primarykeys, sequences, storedprocedures, tables, triggers, uniqueconstraints, views.

If null, default types are columns, foreignkeys, indexes, primarykeys, tables, uniqueconstraints, views.

Liquibase Secure 5.1.0+. Snowflake accepted values are: catalogs, checkconstraints, data, databasepackage, databasepackagebody, FileFormat, foreignkeys, functions, indexes, primarykeys, sequences, SnowflakeDynamicTable, SnowflakeDynamicTableColumn, SnowflakeStage, SnowflakeStandardTable, SnowflakeStandardTableColumn, SnowflakeView, SnowflakeViewColumn, storedprocedures, and triggers. Note: For Snowflake, unique constraints are not snapshotted as standalone objects. Instead, uniqueness is captured as the isUnique attribute on the column definition.

Snowflake view and table support has been enhanced with four Snowflake-specific view and table objects: Snowflake standard views, Snowflake materialized views, Snowflake standard tables, and Snowflake dynamic tables. The generic Liquibase VIEW and TABLE objects are supported for backward compatibility in CRUD operations only and do not support database inspection. For full Snowflake functionality, use the Snowflake standard view, Snowflake standard table, and Snowflake dynamic table objects. The Snowflake materialized view objects support CRUD operations.

Note: The diff types checkconstraints, databasepackage, databasepackagebody, functions, storedprocedures, triggers, and Snowflake-specific values require Liquibase Secure.

Optional

LIQUIBASE_COMMAND_DRIVER=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_DRIVER=<string>

The JDBC driver class

Optional

LIQUIBASE_COMMAND_DRIVER_PROPERTIES_FILE=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_DRIVER_PROPERTIES_FILE=<string>

The JDBC driver properties file

Optional

LIQUIBASE_COMMAND_EXCLUDE_OBJECTS=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_EXCLUDE_OBJECTS=<string>

Objects to exclude from diff

Optional

LIQUIBASE_COMMAND_IGNORE_MISSING_REFERENCES=[true|false]

Controls behavior when snapshots reference objects from schemas not included in the snapshot (like cross-schema triggers or foreign keys) Default: false

Optional

LIQUIBASE_COMMAND_INCLUDE_CATALOG=<true|false>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_INCLUDE_CATALOG=<true|false>

If true, the catalog will be included in generated changesets. Default: false

Optional

LIQUIBASE_COMMAND_INCLUDE_OBJECTS=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_INCLUDE_OBJECTS=<string>

Objects to include in diff

Optional

LIQUIBASE_COMMAND_INCLUDE_SCHEMA=<true|false>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_INCLUDE_SCHEMA=<true|false>

If true, the schema will be included in generated changesets. Default: false.

When specifying multiple schemas see Diff multiple schemas in Liquibase for file path considerations when same-named objects exist across schemas.

Optional

LIQUIBASE_COMMAND_INCLUDE_TABLESPACE=<true|false>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_INCLUDE_TABLESPACE=<true|false>

Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false.

Optional *

LIQUIBASE_COMMAND_LABEL_FILTER=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_LABEL_FILTER=<string>

Specifies the label filter to generate and apply to all changesets in your changelog. Useful to set many labels quickly. Similar to the set-labels command. Available in Liquibase 4.24.0 and later.

Labels are tags you can add to changesets to control which changeset will be executed in any migration run.

After generating changesets with labels, to deploy specific changes according to these labels, you must run a command that specifies a label filter. For example, update --label-filter=<xyz>.

Optional

LIQUIBASE_COMMAND_OBJECT_CHANGELOGS=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_OBJECT_CHANGELOGS=<string>

Generates a separate changelog for each object. Valid values: all (generate changelogs for all object types), table, view, dml, triggers, functions, sequences, storedprocedures, packages, packagebodies, checkconstraints, indexes, foreignkeys, primarykeys, uniqueconstraints, and none. Default: none.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

LIQUIBASE_COMMAND_OUTPUT_SCHEMAS=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_OUTPUT_SCHEMAS=<string>

Lets you replace the schemas in the output changelog. This is a CSV list. The parameter size must match --schemas. If you have three items names in --schemas, you must also have three items in --output-schemas.

Example: liquibase generate-changelog --schemas=a,b,c --output-schemas=d,e,f

Optional

LIQUIBASE_COMMAND_OVERWRITE_OUTPUT_FILE=<true|false>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_OVERWRITE_OUTPUT_FILE=<true|false>

Determines whether generate-changelog can overwrite an existing changelog, including one specified in --changelog-file. Default: false.

Optional

LIQUIBASE_COMMAND_PASSWORD=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_PASSWORD=<string>

Password to connect to the target database.

Optional

LIQUIBASE_COMMAND_REPLACE_IF_EXISTS_TYPES=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_REPLACE_IF_EXISTS_TYPES=<string>

Specify Change Types you want to target. Liquibase sets replaceIfExists="true" on these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

LIQUIBASE_COMMAND_RUN_ON_CHANGE_TYPES=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_RUN_ON_CHANGE_TYPES=<string>

Specify Change Types you want to target. Liquibase sets runOnChange="true" on changesets containing solely these Change Types: createFunction, createPackage, createPackageBody, createProcedure, createTrigger, and createView. Liquibase 4.26.0+. Default: <none>.

Optional

LIQUIBASE_COMMAND_SCHEMAS=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_SCHEMAS=<string>

Specifies database schemas you want to include

Optional

LIQUIBASE_COMMAND_SKIP_OBJECT_SORTING=<true|false>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_SKIP_OBJECT_SORTING=<true|false>

When true, skips Liquibase's dependency-based object ordering. By default, Liquibase 5.2 and later automatically orders changesets so they can be deployed without manual reordering.

Supported for: Oracle, Postgres, SQL Server, MySQL, MariaDB, DB2, Snowflake, Databricks, MongoDB, and BigQuery.

Optional

LIQUIBASE_COMMAND_USERNAME=<string>

LIQUIBASE_COMMAND_GENERATE_CHANGELOG_USERNAME=<string>

Username to connect to the target database.

Optional

The generate-changelog command supports formatted SQL output. To use it, specify a changelog filename in the format changelog.<database short name>.sql. Liquibase infers the target database from the short name embedded in the filename.

Database short names

Database

Short name

Example filename

Oracle

oracle

changelog.oracle.sql

MySQL

mysql

changelog.mysql.sql

MariaDB

mariadb

changelog.mariadb.sql

PostgreSQL

postgresql

changelog.postgresql.sql

SQL Server

mssql

changelog.mssql.sql

DB2 (LUW)

db2

changelog.db2.sql

DB2 (z/OS)

db2z

changelog.db2z.sql

H2

h2

changelog.h2.sql

HSQLDB

hsqldb

changelog.hsqldb.sql

SQLite

sqlite

changelog.sqlite.sql

Derby

derby

changelog.derby.sql

Firebird

firebird

changelog.firebird.sql

Informix

informix

changelog.informix.sql

Ingres

ingres

changelog.ingres.sql

Sybase

sybase

changelog.sybase.sql

Sybase ASA (SQL Anywhere)

asany

changelog.asany.sql

CockroachDB

cockroachdb

changelog.cockroachdb.sql

EnterpriseDB

edb

changelog.edb.sql

Snowflake

snowflake

changelog.snowflake.sql

Databricks

databricks

changelog.databricks.sql

BigQuery

bigquery

changelog.bigquery.sql

Cassandra

cassandra

changelog.cassandra.sql

Database objects supported by Liquibase

You can use the following object types in Liquibase:

Object type

--diff-types

syntax

Liquibase edition

Catalog

catalogs

Liquibase Open Source

Column

columns

Liquibase Open Source

Data

data

Liquibase Open Source

Foreign key

foreignkeys

Liquibase Open Source

Index

indexes

Liquibase Open Source

NOT NULL constraint

N/A

Liquibase Open Source

Primary key

primarykeys

Liquibase Open Source

Schema

N/A

Liquibase Open Source

Sequence

sequences

Liquibase Open Source

Table

tables

Liquibase Open Source

Unique constraint

uniqueconstraints

Liquibase Open Source

View

views

Liquibase Open Source

Check constraint

checkconstraints

Liquibase Secure

Function

functions

Liquibase Secure

Package

databasepackage

Liquibase Secure

Package body

databasepackagebody

Liquibase Secure

Stored procedure

storedprocedures

Liquibase Secure

Trigger

triggers

Liquibase Secure

Liquibase Secure stored logic behavior

While Liquibase Open Source stores all changesets in a changelog, Liquibase Secure creates a directory called Objects and places the directory at the same level as your changelog.

The Objects directory contains subdirectories for each of the stored logic types:

  • package

  • packagebody

  • function

  • stored procedure

  • trigger

Note: Some database platforms may not support all of these stored logic types.

The generate-changelog command will not create the Objects directory if:

  • You don't have a valid Liquibase Secure license key.

  • Stored logic is not present in the database.

  • The target database does not support the generate-changelog command and stored logic objects.

  • The changelog file is written in formatted SQL. The Objects folder can only be created when generating XML, JSON, or YAML changelogs.

  • There is a pre-existing directory called Objects that was created outside Liquibase.

If your database contains Stored Logic objects, you may have issues attempting to run the generate-changelog command more than once, even with a new changelog name, because the stored logic files already exist in the Objects directory.

To generate a newer version of the changelog file with stored logic objects based on the current database state, you need to delete, rename, or move the Objects directory that was created by running the generate-changelog command previously. Then, you can run the generate-changelog command again.

Note: If there is a pre-existing Objects directory that is not related to Liquibase, you need to delete, rename, or move it to run the generate-changelog command.

If you want to track the history of stored logic objects, use the diff-changelog command. The diff-changelog command structures stored logic files into timestamped directories every time you run the command.