What support does Liquibase have for Teradata?

Supported Liquibase Secure Features

The following Liquibase Secure features are supported with Teradata:

• Policy Checks: Automatically analyze your changelogs to ensure the desired format and behavior, increasing deployment success rates and upholding security best practices. Changelog checks and database checks are both supported over the standard JDBC connection.

• Secrets Management: Keep your authentication data secure by integrating with third-party secrets vaults. AWS Secrets Manager, AWS S3, Azure Key Vault, and HashiCorp Vault are verified to be compatible with Liquibase.

• Structured Logging: Improve database observability by reading Liquibase data in your analytics tool. Use --log-format=json to enable.

• Operation Reports: Generate HTML reports for update, rollback, diff, drift, and check-run operations.

• Flow Files: Create repeatable, portable, and platform-independent Liquibase workflows to run in any CI/CD tool.

• DATABASECHANGELOGHISTORY table (DBCLH): Record a history of all changes made to the database, including changes not tracked by the DATABASECHANGELOG table. Pass --dbclhistory-enabled=true to both the update and dbcl-history commands, or set liquibase.dbclhistory.enabled=true in liquibase.properties to enable globally.

Supported Liquibase Commands

You can use most standard Liquibase commands with Teradata, including:

• Update Commands

• Rollback Commands

• Change Tracking Commands

• Utility Commands

• Flow Commands

• Policy Checks Commands

The following commands are not supported with Teradata:

• snapshot

• diff

• generate-changelog

• diff-changelog

• diff-changelog

• drop-all

• db-doc

Supported Change Types

Standard Liquibase Change Types

All standard Liquibase change types that are compatible with Teradata SQL syntax work as expected, including createTable, addColumn, dropTable, sql, sqlFile, and others.

Modeled BTEQ Change Types

The Teradata extension provides four modeled change types for teams that require structured, auditable changes instead of raw SQL. These change types use the pro-teradata XML namespace.

• bteqInsert -- Generates a Teradata INSERT statement from column definitions. Supports no-raw-SQL compliance policies.

• bteqExport -- Wraps the BTEQ .EXPORT command for exporting query results to a file.

• bteqImport -- Wraps the BTEQ .IMPORT and .REPEAT commands for loading data from files.

• bteqMacro -- Generates a Teradata EXEC statement with typed parameters. Supports STRING, NUMERIC, DATE, TIMESTAMP, and TIME parameter types.

For XML examples and detailed usage of each modeled change type, see Use native executors with Teradata.

Preconditions

All 15 standard Liquibase preconditions are supported with Teradata.

Known Limitations

1. Custom endDelimiter Not Supported

Non-semicolon delimiters (for example, endDelimiter="/") are passed literally to BTEQ, causing syntax errors. BTEQ only recognizes ; as a statement separator.

When runWith="bteq" is set, the native executor framework forces splitStatements=false, so Liquibase does not strip the custom delimiter before forwarding SQL to BTEQ.

Workaround: Use the default semicolon delimiter. For stored procedures that contain internal semicolons, the BTEQ executor automatically uses .COMPILE FILE, so no custom endDelimiter is needed.

2. JAVA_OPTS with Spaces in -D Property Values

Setting JAVA_OPTS="-Dliquibase.bteq.path=/path with spaces/bteq" fails because the Liquibase launcher script expands $JAVA_OPTS without quoting, causing shell word-splitting. This is a launcher-level issue affecting all -D properties with spaces, not specific to BTEQ.

Workaround: Use liquibase.properties, liquibase.bteq.conf, or the LIQUIBASE_BTEQ_PATH environment variable instead. Alternatively, create a symlink to a path without spaces: ln -sf "/Library/Application Support/teradata/client/17.20/bin/bteq" /tmp/bteq_link && JAVA_OPTS="-Dliquibase.bteq.path=/tmp/bteq_link" liquibase update ...

3. CLI Parameters Not Recognized

BTEQ configuration cannot be passed as CLI flags (for example, --bteq-path). This is consistent with other native executors (SqlPlus, Psql, SqlCmd) which also do not expose configuration properties as CLI arguments.

Workaround: Use any of these configuration methods:

• liquibase.properties -- for example, liquibase.bteq.path=/path/to/bteq

• liquibase.bteq.conf -- same key format, placed in the working directory

• Environment variables -- for example, LIQUIBASE_BTEQ_PATH=/path/to/bteq

• --defaults-file -- for example, liquibase --defaults-file custom.properties update ...

4. Database Policy Checks May Not Work Over BTEQ Connections

Database Policy Checks use the JDBC connection to query the target database. Some database-level checks may produce unexpected results when changesets run through the BTEQ native executor, because BTEQ routes SQL outside the standard JDBC path.

Workaround: Run liquibase checks run --checks-scope=changelog to validate changelog compliance before deploying. Changelog-level policy checks are fully supported regardless of executor.