Liquibase allows a dynamic substitution of properties in your changelog. The tokens to replace in your changelog are described using the ${property-name} syntax.

Uses

By substituting values for replacement tokens in the format of ${property-name}, you can use the same changesets to reflect small environmental changes.

For example, your tablespace name in Oracle may differ from environment to environment, but you want to only write one create table changeset that can be used in all of your environments.

Using property substitution in your changelog

You can set property values in Liquibase in several ways. Liquibase assigns these values in the following order:

• As an attribute passed to your Liquibase runner. See the Ant, Maven, or Servlet Listener documentation for more information on how to pass them.

• As a JVM system property. See JAVA_OPTS Environment Variable for more information.

• As an environment variable.

• As a CLI attribute, if executed from the command line. Use the syntax liquibase <command.name> -D<property.name>=<property.value>. On Windows, surround the property name in quotation marks if it contains a dot. For example: -D"property.name"=value.

• In the parameters block (property element of the changelog file itself).

Once a property has been set, it cannot be changed. Also, only the first definition is used, others are skipped.

Note: If the content of ${property-name} does not match a property, it is left as-is and it is not removed. The supported format includes alphanumeric characters, +, -, . , and _.

Defining properties with contexts

You can define multiple values for the same property by associating each with a specific context. Looking at the following example code, when Liquibase runs with --context=DEV, the ${tblsp.name} token will be replaced with tblsp_cms_dev. This lets you safely use a single changelog across all environments.

Be sure to place <property> tags at the beginning of the changelog, before any <changeSet> definitions.

<property name="tblsp.name" value="tblsp_cms_dev" context="DEV"/> <property name="tblsp.name" value="tblsp_cms_test" context="TEST"/> <property name="tblsp.name" value="tblsp_cms_qa" context="QA"/> <property name="tblsp.name" value="tblsp_cms" context="UAT,PROD"/>

Example Changelog with context-based properties

The first 3 lines of this example changelog provide an additional example of context-based properties being used.

<property name="TS_NAME" value="DEV_TS" context="DEV"/> <property name="TS_NAME" value="TEST_TS" context="TEST"/> <property name="TS_NAME" value="PROD_TS" context="PROD"/>

Example Changelog with context-based properties

The first 3 lines of this example changelog provide an additional example of context-based properties being used.

Example CLI and properties file usage

The following examples show different ways to assign values to your changelog properties depending on how you're running Liquibase. Choose the approach that best fits your workflow or automation needs.

Liquibase Properties file: Useful for teams or CI/CD pipelines requiring a reusable, version-controlled configuration.

parameter.TS_NAME=DEV_TS

Command-line (CLI) Attribute: This attribute is Good for quick, one-off executions or scripting where you want to override values dynamically at runtime.

liquibase update -DTS_NAME=DEV_TS

Environment Variable: Ideal for environments where the OS or deployment system securely manages sensitive values (like credentials or paths). Especially common in containerized or cloud environments.

export TS_NAME=DEV_TS

sql and sqlFile

You can use property substitution with the sql and sqlFile Change Types. Note that Liquibase obtains the checksum of a sql changeset after substituting any properties you specify. However, it obtains the checksum of a sqlFile changeset before substituting the properties in the external SQL file.

This affects the behavior of attributes like runOnChange. For example, suppose you set an environment variable ENV_EXAMPLE=value and you use property substitution for ENV_EXAMPLE in two changesets: sql and sqlFile. If you deploy your changes with the update command, ENV_EXAMPLE is substituted for the value you set. Suppose each changeset is also labeled with runOnChange=true, so if you run the update command, the changesets rerun only if their contents have changed since the last deployment. If you then set ENV_EXAMPLE=new_value and run update, only the sql changeset runs a second time.

Nested properties

Available attributes