generateChangeLog command

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


The generateChangeLog 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.

Running the generateChangeLog command

To generate a changelog:

  1. Configure the file to include your driver, classpath, and URL for the database you want to capture.

Note: For more information on how to configure your file, see the Creating and configuring a file topic. Instead of using a file, you can also pass the necessary information on the command line.

  1. Open your CLI and run the following command:
liquibase --changeLogFile=dbchangelog.xml generateChangeLog

Note: If you want to create an SQL changelog file, add your database type name when specifying the changelog file: liquibase generateChangeLog. Replace .oracle.sql with your database type. When in doubt about your database type name, check Supported Databases.

generateChangeLog global attributes

Attribute Definition Requirement
--changeLogFile Specifies the root changelog. Required
--url Specifies the JDBC database connection URL. Required
--username Specifies the database username. Required
--password Specifies the database password. Required
--liquibaseProLicenseKey Specifies your Liquibase Pro license key. Optional

generateChangeLog command attributes

Attribute Definition Requirement
--defaultCatalogName=<name> Specifies the default database catalog to use. Optional
--defaultSchemaName=<name> Specifies the default database schema to use. Optional
--schemas=<name1, name2> Specifies database schemas you want to include. Optional

Uses the names as schemaName instead of the real names on the generateChangeLog command.

--includeCatalog=[boolean] Includes the catalog in a generated changesets if the value is true. The default value is false. Optional
--includeSchema=[boolean] Includes the schema in a generated changesets if the value is true. The default value is false. Optional
--includeTablespace=[boolean] Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false. Optional *
--dataOutputDirectory=DIR Sends the data output as a CSV file in the given directory. Optional
--diffTypes Includes a list of diff types in a changelog file expressed as a comma-separated list (without spaces) from: catalog,tables,functions,views,columns,indexes,foreignkeys,primarykeys,
Optional **

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

** If the --diffTypes value is null, then the default types will be: tables, views, columns, indexes, foreignkeys, primarykeys, uniqueconstraints.


The generateChangeLog 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.postgresql.sql, you will get changelogs formatted in YAML, JSON, or SQL respectively.

Additional functionality with Liquibase Pro

While Liquibase Community stores all changesets in a changelog, Liquibase Pro creates a directory called Objects and places the directory at the same level as your changelog. The Objects directory contains a subdirectory for each of the following stored logic types:

  • package
  • packagebody
  • function
  • stored procedure
  • trigger
  • view

Note: Not all database platforms support all stored logic types that are listed.