Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Amazon Redshift will no longer support the use of Python UDFs after June 30, 2026. We will start enforcing it in phases. For more information on the details of Python end of life and migration options, see the blog post that was published on June 30, 2025.

Materialized views stored as Apache Iceberg tables

You can create materialized views that store their data as Apache Iceberg tables in Amazon S3 or Amazon S3 Table Buckets. Unlike standard Amazon Redshift materialized views, which store data internally in Redshift Managed Storage (RMS), Iceberg materialized views are stored as standard Iceberg tables and are accessible to any analytics engine that supports the Iceberg format, including Apache Spark, Amazon Athena, and Trino.

Iceberg materialized views combine Amazon Redshift's query optimization and incremental refresh capabilities with Iceberg's open table format. You can create, refresh, and drop Iceberg materialized views using the same SQL commands as standard materialized views, with the addition of the USING ICEBERG clause during creation.

Iceberg materialized views are supported on Redshift Serverless and provisioned clusters with RG instance types. RA3 and DC2 instance types are not supported.

For information about SQL commands used to create and manage Iceberg materialized views, see the following command topics:

How Iceberg materialized views work

When you create an Iceberg materialized view, Amazon Redshift does the following:

When you refresh an Iceberg materialized view, Amazon Redshift compares the current source table Iceberg snapshots against the snapshots recorded at the last refresh. If changes are detected, Amazon Redshift either computes and applies only the changed data (incremental refresh) or performs a full recomputation.

Source table requirements

Source tables for Iceberg materialized views must meet the following requirements:

Cross-engine interoperability

Iceberg materialized views created by Amazon Redshift appear as standard Iceberg tables in the Amazon Glue Data Catalog. Other analytics engines can read them using standard Iceberg table access patterns without any additional configuration.

The following restrictions apply:

Incremental refresh

Amazon Redshift performs incremental refresh when the materialized view definition supports it. Incremental refresh reads only the data that changed in source tables since the last refresh and applies those changes to the materialized view.

Incremental refresh is supported for materialized views that use:

Amazon Redshift automatically falls back to full refresh when:

Concurrent refresh

Multiple Amazon Redshift clusters or workgroups can attempt to refresh the same Iceberg materialized view concurrently. Amazon Redshift uses optimistic concurrency control (OCC) through the Amazon Glue Data Catalog's conditional update mechanism to ensure that only one refresh succeeds. If a concurrent refresh is detected, Amazon Redshift checks whether the materialized view is still stale. If another cluster has already completed the refresh, the operation returns success without redoing work.

Compaction and table maintenance

For Iceberg materialized views stored in Amazon S3 Table Buckets, Amazon S3 Tables automatically manages compaction and data file optimization. No user action is required.

For materialized views stored in general-purpose Amazon S3 buckets (specified via the LOCATION parameter), Amazon Redshift doesn't perform compaction. Over time, incremental refresh produces many small data files that can degrade read performance. To maintain read performance, use the following recommended practices:

For source tables, configure snapshot retention to exceed your expected refresh interval. When source table snapshots expire before the next refresh, Amazon Redshift can no longer compute an incremental delta and falls back to full refresh.

Security considerations

Permissions

The following permissions are required:

For information about creating IAM roles for Amazon Redshift and granting Amazon Lake Formation permissions, see Getting started with Amazon Redshift Spectrum. To verify that the IAM role has the required permissions on source tables, use the Amazon Lake Formation console or the GetEffectivePermissionsForPath API. To verify that the target Amazon Glue database exists and the role has access, use the GetDatabase API.

The following example verifies that the IAM role has SELECT permission on a source table via Amazon Lake Formation:

aws lakeformation list-permissions \
    --principal DataLakePrincipalIdentifier=arn:aws:iam::123456789012:role/myspectrum_role \
    --resource '{"Table":{"DatabaseName":"mydb","Name":"orders"}}'

The following example verifies that the target Amazon Glue database exists and is accessible:

aws glue get-database --name mydb

Snapshot history visibility

Iceberg materialized views store data as standard Iceberg tables with full snapshot history. A reader with access to the underlying Iceberg files can compare successive snapshots to observe which rows were added or removed between refreshes.

For aggregated materialized views (those with GROUP BY and aggregate functions), the visible delta is limited to changes in aggregate values, not individual source table rows. For non-aggregated materialized views, the delta corresponds to the specific rows that changed in the materialized view output.

This behavior is inherent to the Iceberg table format. Any Iceberg table that undergoes incremental writes exposes the same property.

To mitigate this behavior:

Monitoring

Refresh history

Refresh operations performed by the local cluster are logged to SVL_MV_REFRESH_STATUS. Query this view to check refresh timing, status, and whether refresh was incremental or full.

SELECT mv_name, starttime, endtime, status
FROM svl_mv_refresh_status
WHERE mv_name = 'daily_revenue'
ORDER BY starttime DESC
LIMIT 10;

Note that this system view only records refreshes performed by the local cluster. If multiple clusters refresh the same Iceberg materialized view, each cluster's system tables show only its own refresh history.

Discovering Iceberg materialized views

Use SVV_EXTERNAL_TABLES to find Iceberg materialized views in your external schemas:

SELECT schemaname, tablename, location
FROM svv_external_tables
WHERE tabletype = 'MATERIALIZED VIEW';

STV_MV_INFO doesn't include Iceberg materialized views.

Limitations

You can't define an Iceberg materialized view that references or includes any of the following:

The following SQL constructs are allowed in the materialized view definition but force full refresh instead of incremental refresh:

Additional limitations: