SECURE 5.2: Best practices for deploying to Teradata schemas with varying schema names in the pipeline

Best practices for deploying to Teradata schemas with varying schema names in the pipeline

Last updated: June 18, 2026

As database changes move through a pipeline, the target schema name often differs from one environment to the next. For example, the same change might deploy to a DEV schema, then a TEST schema, and finally a PROD schema. Rather than maintaining a separate changelog for each environment, use Liquibase property substitution to parameterize the schema name so a single changelog works everywhere.

Liquibase performs variable substitution in changelog and changeset files. As long as the property is defined, you can reference it with the ${property_name} syntax. For more detail, see What is property substitution?.

Reference the schema name with a property

Reference the target schema with ${TARGET_SCHEMA} in your changeset. The changeset stays identical in every environment. Only the value of TARGET_SCHEMA changes.

<changeSet id="1" author="liquibase">
    <createTable schemaName="${TARGET_SCHEMA}" tableName="employee">
        <column name="name" type="VARCHAR(100)"/>
        <column name="environment" type="VARCHAR(100)"/>
        <column name="url" type="VARCHAR(100)"/>
    </createTable>
</changeSet>

{
  "databaseChangeLog": [
    {
      "changeSet": {
        "id": "1",
        "author": "liquibase",
        "changes": [
          {
            "createTable": {
              "schemaName": "${TARGET_SCHEMA}",
              "tableName": "employee",
              "columns": [
                { "column": { "name": "name", "type": "VARCHAR(100)" } },
                { "column": { "name": "environment", "type": "VARCHAR(100)" } },
                { "column": { "name": "url", "type": "VARCHAR(100)" } }
              ]
            }
          }
        ]
      }
    }
  ]
}

databaseChangeLog:
  - changeSet:
      id: 1
      author: liquibase
      changes:
        - createTable:
            schemaName: ${TARGET_SCHEMA}
            tableName: employee
            columns:
              - column:
                  name: name
                  type: VARCHAR(100)
              - column:
                  name: environment
                  type: VARCHAR(100)
              - column:
                  name: url
                  type: VARCHAR(100)

--liquibase formatted sql

--changeset liquibase:1
CREATE TABLE ${TARGET_SCHEMA}.employee (
    name VARCHAR(100),
    environment VARCHAR(100),
    url VARCHAR(100)
);

<changeSet id="1" author="liquibase">
    <createTable schemaName="${TARGET_SCHEMA}" tableName="employee">
        <column name="name" type="VARCHAR(100)"/>
        <column name="environment" type="VARCHAR(100)"/>
        <column name="url" type="VARCHAR(100)"/>
    </createTable>
</changeSet>

{
  "databaseChangeLog": [
    {
      "changeSet": {
        "id": "1",
        "author": "liquibase",
        "changes": [
          {
            "createTable": {
              "schemaName": "${TARGET_SCHEMA}",
              "tableName": "employee",
              "columns": [
                { "column": { "name": "name", "type": "VARCHAR(100)" } },
                { "column": { "name": "environment", "type": "VARCHAR(100)" } },
                { "column": { "name": "url", "type": "VARCHAR(100)" } }
              ]
            }
          }
        ]
      }
    }
  ]
}

databaseChangeLog:
  - changeSet:
      id: 1
      author: liquibase
      changes:
        - createTable:
            schemaName: ${TARGET_SCHEMA}
            tableName: employee
            columns:
              - column:
                  name: name
                  type: VARCHAR(100)
              - column:
                  name: environment
                  type: VARCHAR(100)
              - column:
                  name: url
                  type: VARCHAR(100)

--liquibase formatted sql

--changeset liquibase:1
CREATE TABLE ${TARGET_SCHEMA}.employee (
    name VARCHAR(100),
    environment VARCHAR(100),
    url VARCHAR(100)
);

Supply the value for each environment

The changeset never changes. You supply a different value for TARGET_SCHEMA in each stage of your pipeline. For a pipeline, the recommended approach is context-based properties: declare a value for each context at the top of your changelog, before any changesets.

<property name="TARGET_SCHEMA" value="DEV_SCHEMA"  context="DEV"/>
<property name="TARGET_SCHEMA" value="TEST_SCHEMA" context="TEST"/>
<property name="TARGET_SCHEMA" value="PROD_SCHEMA" context="PROD"/>

{
  "databaseChangeLog": [
    { "property": { "name": "TARGET_SCHEMA", "value": "DEV_SCHEMA", "context": "DEV" } },
    { "property": { "name": "TARGET_SCHEMA", "value": "TEST_SCHEMA", "context": "TEST" } },
    { "property": { "name": "TARGET_SCHEMA", "value": "PROD_SCHEMA", "context": "PROD" } }
  ]
}

databaseChangeLog:
  - property:
      name: TARGET_SCHEMA
      value: DEV_SCHEMA
      context: DEV
  - property:
      name: TARGET_SCHEMA
      value: TEST_SCHEMA
      context: TEST
  - property:
      name: TARGET_SCHEMA
      value: PROD_SCHEMA
      context: PROD

<property name="TARGET_SCHEMA" value="DEV_SCHEMA"  context="DEV"/>
<property name="TARGET_SCHEMA" value="TEST_SCHEMA" context="TEST"/>
<property name="TARGET_SCHEMA" value="PROD_SCHEMA" context="PROD"/>

{
  "databaseChangeLog": [
    { "property": { "name": "TARGET_SCHEMA", "value": "DEV_SCHEMA", "context": "DEV" } },
    { "property": { "name": "TARGET_SCHEMA", "value": "TEST_SCHEMA", "context": "TEST" } },
    { "property": { "name": "TARGET_SCHEMA", "value": "PROD_SCHEMA", "context": "PROD" } }
  ]
}

databaseChangeLog:
  - property:
      name: TARGET_SCHEMA
      value: DEV_SCHEMA
      context: DEV
  - property:
      name: TARGET_SCHEMA
      value: TEST_SCHEMA
      context: TEST
  - property:
      name: TARGET_SCHEMA
      value: PROD_SCHEMA
      context: PROD

Then select the environment at deploy time by passing its context. For example, --context-filter=DEV makes ${TARGET_SCHEMA} resolve to DEV_SCHEMA, so the change deploys to the DEV schema. Pass the context whichever way fits your pipeline, or override the value directly with -D (useful for formatted SQL changelogs or pipeline-generated names).

Be sure to:

Replace your_database_url with your Teradata connection URL. For example, jdbc:teradata://your_hostname/DATABASE=your_database
Replace your_username and your_password with your credentials
Replace DEV (or DEV_SCHEMA) with the context or schema for the environment you are deploying to

liquibase update \
  --changelog-file=changelog.xml \
  --context-filter=DEV \
  --url=your_database_url \
  --username=your_username \
  --password=your_password

# liquibase.properties
contextFilter: DEV

export LIQUIBASE_CONTEXT_FILTER=DEV

liquibase update \
  --changelog-file=changelog.xml \
  --url=your_database_url \
  --username=your_username \
  --password=your_password \
  -DTARGET_SCHEMA=DEV_SCHEMA

liquibase update \
  --changelog-file=changelog.xml \
  --context-filter=DEV \
  --url=your_database_url \
  --username=your_username \
  --password=your_password

# liquibase.properties
contextFilter: DEV

export LIQUIBASE_CONTEXT_FILTER=DEV

liquibase update \
  --changelog-file=changelog.xml \
  --url=your_database_url \
  --username=your_username \
  --password=your_password \
  -DTARGET_SCHEMA=DEV_SCHEMA

Vary included paths by environment

You can use the same approach to control which files Liquibase includes. Reference a property in an includeAll path so each environment pulls in its own set of scripts. As with the schema name, you write ${TARGET_ENV} once and supply its value per environment.

<includeAll path="scripts/${TARGET_ENV}/"/>

{
  "databaseChangeLog": [
    { "includeAll": { "path": "scripts/${TARGET_ENV}/" } }
  ]
}

databaseChangeLog:
  - includeAll:
      path: scripts/${TARGET_ENV}/

--liquibase formatted sql

--includeAll path:scripts/${TARGET_ENV}/

<includeAll path="scripts/${TARGET_ENV}/"/>

{
  "databaseChangeLog": [
    { "includeAll": { "path": "scripts/${TARGET_ENV}/" } }
  ]
}

databaseChangeLog:
  - includeAll:
      path: scripts/${TARGET_ENV}/

--liquibase formatted sql

--includeAll path:scripts/${TARGET_ENV}/

When TARGET_ENV is set to PROD, Liquibase replaces the variable with PROD and includes all of the files from the scripts/PROD/ directory.

Best practices for deploying to Teradata schemas with varying schema names in the pipeline

Reference the schema name with a property

XML

JSON

YAML

SQL

Supply the value for each environment

XML

JSON

YAML

CLI

liquibase.properties

Environment variable

-D override

Vary included paths by environment

XML

JSON

YAML

SQL