Iceberg Materialized Views: Compute Once, Share Everywhere

Iceberg materialized views, which Amazon Redshift added on October 5, 2026, go after one of the dumbest line items in a modern data budget: paying three or four engines to calculate the same number, and then paying people to argue about why the numbers differ. With this release, Redshift can compute a result once and store it as an open Apache Iceberg table that Athena, Spark, AWS Glue, SageMaker notebooks and third-party engines read directly. If you run a lakehouse with more than one query engine, this belongs on your roadmap.

The problem: everyone computes the same metric, differently

Here is the pattern we see in almost every mid-size data platform. The finance team’s revenue dashboard runs on Redshift. The data science group rebuilds the same daily revenue rollup in Spark because they need it as features. The reporting team writes their own version in Athena. Each engine scans the same raw data, each team maintains its own logic, and every quarter someone discovers the three versions disagree by a few percent.

That is two costs stacked together. There is the compute you pay for repeatedly, which grows with every new consumer. And there is the trust cost: executives who stop believing dashboards, and analysts who spend days on reconciliation instead of analysis. Neither shows up as one neat line on the AWS bill, which is exactly why it survives so long.

What Iceberg materialized views change

A materialized view is a saved, precomputed query result. Redshift has had them for years, but they lived inside Redshift’s own storage, useful only to Redshift users. The new version writes the result as a standard Iceberg table in Amazon S3 or in S3 table buckets, catalogued in the AWS Glue Data Catalog like any other table. Any engine that speaks Iceberg can read it. No exports, no copies, no second pipeline.

For your engineers it is one SQL statement, the same command they already use plus a clause:

CREATE MATERIALIZED VIEW lake.daily_revenue USING ICEBERG ... AS SELECT ...;

Redshift keeps the result current with incremental refresh, which processes only the data that changed since the last run instead of starting over. That is where most of the savings live, and also where the fine print lives. More on that below.

The money: what consolidation is worth

AWS’s launch post includes an illustrative estimate: a mid-size daily aggregation (1 TB in, 100 GB out) computed separately across four engines costs about $7,500 a month, against roughly $1,500 a month for one Redshift refresh that everyone reads. Treat that as a directional example, not a quote. AWS itself says savings vary by workload.

The economic logic holds, though. Consumers read the finished table at standard S3 request and storage rates, with no extra compute on their side. Your cost becomes one refresh plus storage, instead of N full computations. The more engines and teams you consolidate, the bigger the gap. When you model it, include three things the brochure skips: Redshift compute for refreshes, S3 storage for the view and its history, and the cost of the occasional full recompute when incremental refresh does not apply. Then add the cheapest win of all: the engineering hours your teams stop spending on maintaining three copies of the same logic and reconciling the results every month.

One open table, many engines: the strategic bit

The bigger story is not the compute savings. It is that your most expensive, most important results stop being trapped in one product. Iceberg is an open table format, so the precomputed result is readable by whatever engine your teams prefer this year and next. That is a hedge against lock-in that does not require you to give up a fast warehouse. Pretty good deal for a database feature.

It also gives you a clean operating model. Redshift is the producer: it owns the transformation logic and is the only engine that can refresh or drop the views it creates. Everyone else is a consumer. One definition, one owner, one number. For the hottest interactive dashboards, AWS recommends also loading the result into a native Redshift materialized view, because reading from S3 will not beat Redshift’s internal storage for sub-second response. Open by default, fast where it counts.

Risk and governance: read this before you sign off

• Coarse-grained access only. AWS Lake Formation can grant or deny the whole view, but row-level and column-level filters are not supported on these views. Anything that needs per-user filtering stays out, or gets split into separate views.
• History is visible. Iceberg keeps snapshots, and the Redshift documentation warns that anyone with access to the underlying files can compare them and see what changed between refreshes. For sensitive data, restrict file access and shorten snapshot retention.
• Deleting is a two-step job. Dropping a view removes the catalog entry, not the data in S3. Your retention and deletion policies need to account for that.
• Same account, same Region. Source tables must sit in the same AWS account and Region as the view. Cross-account data meshes need a different design.

The prerequisites that turn into budget items

Platform. The feature runs only on Redshift Serverless and on provisioned clusters using the new Graviton-based RG instances. Older RA3 and DC2 clusters are not supported. AWS positions Redshift RG as up to 2.4x faster on Iceberg queries than RA3 at 30% lower cost per vCPU, so for many teams the migration pays for itself. It is still a project, so plan it as one.

Operations. These views do not refresh themselves. Someone has to schedule refreshes, ideally right after new data lands, and someone has to watch for the expensive full recomputes that certain query patterns trigger. If the views live in ordinary S3 buckets, someone also owns file compaction. Choosing S3 table buckets hands that maintenance to AWS, which is usually the right call.

How we would roll it out

1. Find the duplicated metric. Pick one aggregate that at least three teams compute independently. Revenue, active customers and inventory positions are the usual suspects.
2. Confirm the platform. Serverless or RG. If you are on RA3, fold the migration into the business case.
3. Build it once, measure twice. Create the view, point the other engines at it, and compare the cost of the old duplicated jobs against the new refresh for a month.
4. Assign ownership. The platform team owns definitions and refresh schedules; consuming teams own their reports. Write it down.

The first time finance, data science and reporting quote the same number in the same meeting, the feature has paid for itself in calendar time alone. Pricing for the compute side sits on the Redshift pricing page.

ENKOMPASS IS HERE TO HELP

At Enkompass (enkompass.net), this is our home turf. We help teams consolidate duplicated analytics onto shared Redshift and Iceberg lakehouses on AWS, from the RG migration and cost model to the governance and refresh operations that keep one number trustworthy. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.