Spark and Athena can now read Redshift materialized views kept in Iceberg format

The cost argument in the dev.to write-up rests on one example. If three engines run the same calculation, the company pays for that compute three times. With a shared Iceberg view, one engine does the work and the others consume the result ^[6]. On those terms, compute for that calculation falls by about two-thirds ^[12]. The example assumes every run costs the same and every read costs nothing ^[12].

Two conditions have to hold before that figure carries over to a real stack. Reading the stored view in Athena or Spark has to cost much less than recomputing the query there. The jobs on those engines also have to be rewritten to read the view instead of re-running the SQL against base tables. That second condition means a migration for every consuming job.

Freshness is where the write-up is least careful. The author says AI agents reading a shared view are less likely to encounter stale or conflicting data ^[9]. The conflicting part holds, because there is one copy. The stale part does not follow. The view is a stored snapshot ^[2], so a reader is exactly as current as the last refresh.

The write-up does not say how the views refresh, which catalog Spark and Athena use to find them, or what AWS charges for them. Those details decide whether a team can switch an ETL job off or only shorten it.

I think storing the shared result in an open table format is the right design. It takes the precomputed layer out of any single engine. The author's point that query optimizations stop being locked to one vendor follows directly from that ^[10]. The write-up also promises that engineers will focus on high-value tasks instead of basic maintenance ^[11]. I would wait for the refresh documentation before booking that time.

The first test I would run is short. Point Athena at the view, update a base table in Redshift, and time how long the two disagree.