USER MANUALS

Vendor-specific capabilities for schema evolution

Each database adapter has its own capabilities regarding schema evolution. In this section you can see the current limitations for database vendors regarding schema evolution for full materialized views.

Adapt schema

Adapt schema is not available for the following database adapters:

  • Amazon Athena

  • Clickhouse

  • Impala

  • Impala Kudu

  • Mysql on version 7 and lower

  • Netezza on version 6 and lower

  • Spark

  • Trino

Database adapters without adapt schema available are also not using any of the specific features like drop, retype or rename columns.

Drop column

The column cleanup feature is not available for the following database adapters:

  • DB2

  • Databricks

  • Bigquery

  • Hive

  • Netezza

  • Presto

  • Sybase ASE

  • Sybase IQ

  • Vertica

  • Yellowbrick

Rename column

The column rename operation is not available for the following database adapters:

  • Azure Synapse

  • Databricks

  • Bigquery

  • Hive

  • Presto

  • Sybase ASE

  • Sybase IQ

Some adapters do support column renaming but only if no custom catalog/schema is configured:

  • Azure SQL

  • SQLServer-based databases

  • Microsoft Fabric Data Warehouse

  • PostgreSQL-based Databases

Change column type

Changing the column type is not available for the following database adapters:

  • Redshift

  • Azure Synapse

  • Databricks

  • DB2

  • Derby

  • Bigquery

  • Hive

  • Netezza

  • Oracle

  • Presto

  • Snowflake

  • Sybase ASE

  • Sybase IQ

  • Teradata

  • Vertica

  • Yellowbrick

Additional retrictions

Add row privileges: For schema adaptation to work properly, the user must have sufficient privileges for the required table operations. For example, Presto does not enable “add column” privileges by default; you must set the hive.allow-add-column=true property to grant them.

DDL on transactions: Because Azure Synapse SQL does not support DDL statements within transactions, modifications to materialization tables are executed outside of the VDP distributed transaction. This can lead to data inconsistencies if a rollback occurs after the materialization table has been altered.

Add feedback