Amazon Redshift stores materialized views as open Iceberg tables readable by every engine
As of October 5, 2026, Redshift can write the results of its materialized views as Apache Iceberg tables in S3, queryable by Athena, Spark, Glue, and SageMaker with no copy in between. For a team that wants its precomputed aggregates open to every engine instead of locked inside Redshift, this is a concrete pivot.
October 5, 2026. AWS announces Iceberg materialized views for Amazon Redshift on its Big Data blog: a single precomputed aggregation can now be stored as an Apache Iceberg table in S3, readable by Athena, Spark, Glue, and SageMaker — with no copy and no intermediate pipeline. The post’s tagline is “materialize once, query anywhere.” For a data team whose transformations live in Redshift but whose consumers are scattered, it closes an old trade-off: performance and openness always stopped meeting somewhere along the way.
What the feature actually does
A materialized view (MV) precomputes an expensive join or aggregation once, then serves that result instead of rerunning the computation on every query. Until now, in Redshift, that result lived in the proprietary Redshift Managed Storage (RMS): fast, but unreadable by any external engine. The novelty is a single clause: CREATE MATERIALIZED VIEW … USING ICEBERG. The result becomes a standard Iceberg table in S3 or an S3 Table bucket, registered in the AWS Glue Data Catalog.
The flow reads like this. Redshift computes the aggregation once, in SQL your teams already write. The result is stored as an ordinary Iceberg table, governed and discovered like any other table in the Glue catalog. Athena, Spark on EMR, Glue, SageMaker AI — and any Iceberg-compatible engine — read that same table directly. As new data lands, an incremental refresh recomputes only what changed instead of rewriting the whole view.
The gain is one word: interoperability. A team running analytics on Redshift had no simple way to share its most expensive precomputed results with the data science group on Spark or the ad-hoc reporting team on Athena — short of exporting copies or standing up a second transformation stack. Now the same Iceberg table serves as the single source of truth for the most expensive query, shared by every engine.
The backdrop: Redshift RG and Iceberg writes
The feature does not arrive in a vacuum. Earlier this year AWS launched Redshift RG, powered by Graviton, with a purpose-built vectorized query engine for data lakes: vectorized Parquet scans, a smart-prefetch I/O subsystem, partition- and file-level pruning, improved Bloom filters, and automatic Iceberg statistics collection through JIT Analyze. The announced result: Iceberg queries up to 2.4× faster than on RA3, at 30% lower cost per vCPU, with no per-terabyte scan charges on data lake queries.
On that foundation, Redshift could already write to Iceberg tables with full ACID alignment: INSERT, CTAS, UPDATE, DELETE, MERGE. Iceberg materialized views complete the picture by making the acceleration itself portable. The optimization is no longer trapped in a proprietary storage format: it is written into an open standard that other engines in the organization read natively.
Iceberg materialized views are supported on Redshift Serverless and on RG instances — not on RA3 or DC2. Governance relies on IAM permissions on the external schema’s role.
RMS or Iceberg: two tools, two jobs
The real question for an architect is not “which is better” but “where is the result consumed.” AWS itself draws the line, and it is clear.
Use a classic Redshift (RMS) materialized view when you query only from Redshift, when you need the lowest read latency — interactive dashboards, sub-second lookups — and when you want the simplest option for a Redshift-only workload. Reading from RMS is significantly faster than reading an Iceberg table from S3.
Use an Iceberg materialized view when you want the precomputed result readable by engines beyond Redshift without copying, when you are standardizing on Apache Iceberg for interoperability, or when you want to run an end-to-end pipeline in a single engine and share the same open result with every downstream consumer.
The two approaches are complementary. A common pattern is to build and transform data as Iceberg MVs for openness, then load the most latency-sensitive results into an RMS MV for the hottest interactive dashboards. The principle in one line: open by default, fast where it counts.
The operational trap to know about
One cleanup subtlety is worth flagging, because it costs money if discovered too late. DROP MATERIALIZED VIEW removes the Glue catalog entry but does not delete the underlying data in S3. To actually release storage, you have to remove the S3 prefix by hand:
# Remove the MV from the Glue catalog…
DROP MATERIALIZED VIEW iceberg_schema.sales_by_region;
# …then free the data in S3 (must be done manually)
aws s3 rm s3://my-bucket/iceberg_mv_blog/ --recursiveThat is a billing detail, not theory: an Iceberg table left in place keeps occupying S3 storage and generating cost even after the view no longer appears anywhere in the catalog. Teams that drop MVs “to clean up” without purging S3 end up with a lake that grows on its own.
A concrete example, and what it does to the bill
Getting started is a single query. The source table must be an Iceberg table — a native Redshift table cannot serve as the source — and the typical example is an orders table aggregated by region for a daily report:
CREATE MATERIALIZED VIEW iceberg_schema.sales_by_region
USING ICEBERG
AS
SELECT region, SUM(amount) AS total_amount, COUNT(*) AS orders
FROM orders
GROUP BY region;This exact case is the most favorable one: incremental refresh is only supported for COUNT and SUM aggregates with GROUP BY and inner joins. As soon as a view uses DISTINCT, an outer join, a window function, or an aggregate other than COUNT/SUM, Redshift falls back to a full refresh. Choosing columns and aggregates is therefore not neutral: it determines whether you recompute everything or only the delta.
Another point that decides operations: there is no auto-refresh. Unlike RMS materialized views, an Iceberg MV must be refreshed by hand:
REFRESH MATERIALIZED VIEW iceberg_schema.sales_by_region;That is also a cost decision. An Iceberg MV on a large volume does not refresh for free: every refresh consumes Redshift compute. By rewriting only the delta, incremental refresh avoids the cost of a full recompute on every load — and, above all, it removes the hidden cost of the copies and redundant pipelines teams stood up to share the result with other engines. The optimization becomes portable, so the other engines no longer have to recompute it on their side.
One more asymmetry to remember: only Redshift can refresh or drop a materialized view it created. An Iceberg MV created by another engine, such as Spark, is readable by Redshift as a read-only table, but Redshift cannot refresh or drop it. If several engines in your organization write MVs, agree on who owns the refresh for each view before the first one is created — otherwise you will end up with views nobody can update.
Verdict
If all your queries stay inside Redshift, change nothing: the RMS MV remains the fastest, simplest option. If your precomputed results are consumed by several engines — a Spark group, an Athena team, an ML pipeline — move those aggregates to Iceberg MVs: you compute once, everyone reads the same open table, and you delete the copies and redundant pipelines. If you are selling the lock-in argument to leadership, this is the most legible use case in a long time: query optimization itself becomes a portable asset, written in a standard your competitors also read. The caution remains an operator’s reflex — watch the incremental refresh, govern access through IAM, and never forget that DROP does not free S3.