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
--defaultCatalogName=<name> Specifies the default database catalog to use. Optional
--defaultSchemaName=<name> Specifies the default database schema to use. Optional
--driver The JDBC driver class Optional
--driverPropertiesFile The JDBC driver properties file Optional
--excludeObjects Objects to exclude from diff Optional
--includeObjects Objects to include in diff Optional
--liquibaseProLicenseKey Specifies your Liquibase Pro license key. Optional

Note: The username and password attributes are not required for connections and systems which use alternate means of authentication.

generateChangeLog command attributes

Attribute Definition Requirement
--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 **
--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 *

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

--overwriteOutputFile=[boolean] Determines whether generateChangeLog can overwrite an existing changelog, including one specified in --changeLogFile. The default value is false. Optional
--schemas=<name1, name2> Specifies database schemas you want to include. 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: Some database platforms may not support all of these stored logic types.

The generateChangeLog command will not create the Objects directory if:

  • You don't have a valid ProKey
  • There are no stored logic objects in the database
  • The changelog file is written in formatted SQL (the Objects folder can only be created when generating XML, JSON or YAML changelogs)
  • The target database is not supported with the generateChangeLog command and stored logic objects

If your database contains stored logic objects, you may have issues attempting to run the generateChangeLog 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 generateChangeLog command previously. Then, you can run the generateChangeLog 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 generateChangeLog command.

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