Itamar Syn-Hershko
Apache Iceberg cuts compute spend, not storage spend. Public migrations report 35-52% lower platform costs when ELT moves off warehouse pricing, while BI-only workloads mostly pay a migration bill. Here is what the evidence supports, what it costs to run, and when the numbers work.
Short answer: Apache Iceberg saves money on compute, not on storage. Companies that moved ELT and ingestion off warehouse pricing and onto Iceberg tables report 35-52% lower annual platform spend. Companies that only ran BI dashboards on top of it mostly paid for a migration and got the same bill back.
That distinction is the whole story. Apache Iceberg is not a cheaper warehouse. It is a way to stop paying warehouse compute prices for work that never needed a warehouse: landing data, transforming it, backfilling it, and feeding it to engines the warehouse does not run. We have watched this play out across enough client platforms to be blunt about which claims hold up and which ones are vendor marketing. This post goes through the public evidence, the costs nobody puts on the slide, and a decision framework for whether your bill will actually move.
What Iceberg Does and Does Not Make Cheaper
Apache Iceberg is an open table format that adds ACID transactions, schema and partition evolution, and snapshot isolation to Parquet files on object storage, so that Spark, Flink, Trino, ClickHouse, Snowflake and other engines can read and write the same tables. The latest release is Iceberg 1.11.0 from May 2026. Nothing in that definition says "cheaper". Every cost effect is second-order, and each one deserves its own verdict.
| Claim | Evidence | Verdict |
|---|---|---|
| Lower storage cost | Snowflake bills storage at $23/TB/month on demand; S3 Standard is $0.023/GB/month, which is the same $23/TB. Storage was never the margin. | Weak |
| Lower compute cost | New Relic cut annual data platform spend 35-52% by moving ELT from Snowflake to Spark on Iceberg. Airbnb saw over 50% compute savings on its event ingestion framework. | Strong, for ELT-heavy bills |
| Multi-engine access | One copy of the data serving Spark, Flink, Trino, ClickHouse and the warehouse. Eliminates paid duplicate copies and cross-platform ETL. | Strong |
| Faster queries | Grab, Shopify and TRM Labs report 10x to 1000x improvements, but most of the gain came from fixing file layout, replacing JSON, or changing engines at the same time. | Situational |
| Less vendor lock-in | The table format is portable. The catalog that tracks it is the new lock-in point. | Partial |
| Lower total cost of ownership | Only above single-digit terabytes and with a team that can run Spark or Flink. Below that, the platform headcount outweighs the savings. | Scale-dependent |
The storage row surprises people. Cloud warehouses pass object storage through at roughly cost. Snowflake explicitly does not bill for storage on externally managed Iceberg tables, but it never made much money on storage anyway. Anyone quoting "5-10x cheaper storage" is comparing list on-demand warehouse pricing against an archival tier like S3 Glacier Instant Retrieval at $4/TB. The storage saving is real only if you were on on-demand pricing, you tier cold data down, or you were paying to store the same rows twice. If your business case for Iceberg rests on the storage line alone, you do not have a business case.
Where the Savings Actually Come From
The money is in compute arbitrage. A cloud warehouse charges $2 to $4 per credit for every second a virtual warehouse runs, whether that second is serving an analyst's dashboard or copying yesterday's Kafka topic into a staging table. Fivetran's analysis of Snowflake and Redshift research puts ingestion alone at 20-30% of warehouse compute, and one of their customers measured it at 50% before optimization. Add dbt-style transformations and the share of a warehouse bill that is not "queries from humans" is routinely the majority. ChartMogul found 80% of its Snowflake credits went to transformation.
Iceberg lets you move exactly that work onto Spark or Flink running on commodity instances or Kubernetes, at EC2 prices instead of credit prices, and leave the warehouse to do what it is good at. That is the mechanism behind every large public saving, and it is the reason the number is large only when the ELT share is large.
| Company | Migration | Reported result | Source |
|---|---|---|---|
| New Relic | Snowflake to Iceberg on S3, Spark on Kubernetes, Glue catalog | 35-52% reduction in annual data platform spend, 1,000+ datasets | New Relic blog, Apr 2026 |
| Airbnb | Hive/Tez to Spark 3 + Iceberg for event ingestion, 35B+ Kafka messages/day | Over 50% compute saving, 40% shorter job time, over 90% cheaper compaction vs full rewrites | Airbnb Engineering |
| Grab | Hive Parquet to Iceberg as default, petabytes on S3 | One dataset 70s to 6s; one table's daily S3 API cost down up to 95%; one cluster's resource use halved | Grab Engineering |
| Insider | Hive/ORC to Iceberg/Parquet/Zstd on EMR, hundreds of TB | S3 request cost down ~90%, EC2 and EMR cost down ~20% | Insider Engineering |
| TRM Labs | BigQuery and Citus to Iceberg + StarRocks, 115 TB+ largest workload; trigger was on-prem deployability, not cost | 50% better P95 latency, 54% fewer query timeouts; rejected Delta Lake over missing partition evolution | TRM Labs, Jan 2025 |
| Batch DB ingestion to CDC via Debezium, Kafka, Flink and Spark into Iceberg | Data availability 24h+ to 15 minutes; chose merge-on-read because copy-on-write storage cost outweighed its benefit | Pinterest Engineering | |
| Medidata | Enrichment jobs moved from Flink on EKS into Snowflake, writing Glue-managed Iceberg tables | About 80% lower EKS compute bill; compute moved toward the warehouse, not away from it | Snowflake builders blog, Feb 2026 |
| Shopify | Hive tables in gzipped JSON to Iceberg/Parquet via Trino | 95% shorter execution on large tables; a 1.5 PB table went from 3 hours to under 2 minutes | Trino Summit recap |
| Netflix | Incremental processing on existing Iceberg tables with Maestro | Over 80% cost reduction on one playback pipeline, 10.5h to about 1h | Netflix Tech Blog |
| Salesforce | Hive Metastore lake to Iceberg, 4M tables, 50 PB | Qualitative savings from incremental processing; metadata and access control became the bottlenecks | Salesforce Engineering |
Read the table with a skeptical eye. Only New Relic reports a whole-platform dollar figure, and the post attributes it to leaving proprietary pricing for utility infrastructure, not to Iceberg's metadata design. Grab's 95% and Insider's 90% are S3 API request costs, not the S3 bill. Shopify's 1000x is mostly the difference between gzipped JSON and Parquet. Netflix did not migrate anything. TRM's numbers are latency, not money, and their trigger was needing the same platform on-premise, which no managed warehouse can offer. The pattern is real, but the headline percentages are each measuring a different thing.
Two more observations from the record. Medidata is the counter-example worth keeping: once the tables were open, the cheapest place to run enrichment turned out to be inside Snowflake, and the Flink cluster went away. The asset is optionality in both directions, not a one-way exit. And nobody's warehouse actually disappeared. Instacart's publicly listed stack runs Iceberg, Flink, Trino and ClickHouse next to Snowflake and Databricks. Polyglot is the realistic destination.
Ranked by how often they move a real bill, the value sources look like this:
- Compute arbitrage. ELT and backfills run on Spark or Flink at instance prices instead of credit prices.
- Eliminating duplicate copies. One Iceberg table replaces the warehouse copy, the Spark copy, the ML feature copy, and the pipelines that kept them in sync.
- Decoupling cost from data growth. Storage grows at S3 rates; compute grows only when you run something.
- Streaming ingestion. Flink or Kafka Connect writing Iceberg directly, without a warehouse micro-batch loop burning credits every minute. We covered the mechanics in Flink and Iceberg.
- ML and AI access. Training jobs read Parquet directly instead of exporting from the warehouse, and snapshots give reproducible training sets. In a January 2026 survey of 252 data leaders running Iceberg in production, 95% use or plan to use it for AI and ML. The survey was commissioned by a vendor selling Iceberg optimization, so read it as directional.
- Portability as insurance. Real, but it shows up at contract renewal, not on next month's invoice.
What Iceberg Costs You
A lakehouse has bills of its own. Some are one-time, some recur forever, and the recurring ones are the ones that turn a projected saving into a wash.
One-time costs. Rewriting existing data into Parquet with a sane file layout. A metadata spike during conversion: Grab notes that generating Iceberg metadata reads historical data and can trigger a cost spike as files move between S3 storage tiers. Dual-running old and new platforms for months. Rewriting the semantic layer, the dbt project, and every dashboard that pointed at the warehouse. Cutting consumers over one by one.
Recurring costs. Compaction, snapshot expiry and orphan file cleanup are not optional. The Iceberg maintenance docs are explicit that small files inflate metadata and slow queries, and that data files are not deleted until no snapshot references them. Alex Merced's analysis of table maintenance economics puts maintenance compute at 10-25% of query compute on write-heavy tables. Airbnb's warning from Iceberg Summit 2026 is that Flink is excellent for writes and demands extensive ongoing maintenance to keep reads fast. Skip it and you pay in a different currency: Dremio's worked example of a 100,000-file table costs $24,000 a month in GET requests at 10,000 queries a day, and $1,600 after compaction to 2,000 files. Managed maintenance has a price tag too: AWS S3 Tables charges $0.005 per GB and $0.002 per 1,000 objects processed for binpack compaction, plus $0.0265 per GB-month for storage, a 15% premium over S3 Standard. Our Iceberg table maintenance guide covers the schedule that keeps this under control.
The catalog becomes production-critical infrastructure. Every engine resolves table state through the catalog, so a catalog outage is a platform outage. The Iceberg REST catalog spec means Polaris, Lakekeeper, Nessie, Glue, Unity Catalog and Snowflake Open Catalog all speak the same protocol, which is a real improvement over Hive Metastore. It does not make catalogs interchangeable. Glue's REST endpoint does not support view APIs, Unity Catalog's endpoint is read-only for Delta-backed tables, and moving a table between catalogs is a register operation that corrupts data if the table is still registered in the old one. Access control, lineage and credential vending live in the catalog, not the format. You traded warehouse lock-in for catalog lock-in. The trade is usually worth it, but it is a trade. Pick the catalog deliberately and early: follow platform gravity (Unity for Databricks estates, Glue for deep-AWS shops) and default to Polaris when you want engine neutrality, because switching later means moving the governance you built on top of it.
Region discipline and performance give-back. Engines must sit in the same region as the bucket, or cross-region egress at tens of dollars per terabyte eats the compute saving. And read-heavy analytics on Iceberg lands close to native warehouse tables but not on top of them; write-heavy workloads with frequent small inserts still favor native tables because per-write metadata overhead is real. Model the gap as small, not zero.
Governance and headcount. Row-level security, masking, audit logs and data sharing came free with the warehouse. On a lakehouse someone builds or buys them. Salesforce, at 4M tables, found that access control filters and joins became the throughput bottleneck once the metadata layer was fixed. And someone has to run Spark, Flink, the catalog, and the maintenance jobs. If that someone is a new platform engineering hire, subtract their fully loaded cost from the projected saving before presenting it.
The failure mode is documented. Dremio's Alex Merced describes the default outcome of a lift-and-shift warehouse migration as a composite of what he has watched happen repeatedly: eighteen months in, the warehouse is still running, three inconsistent copies of every table exist, half the dashboards point at each one, the nightly ETL runs twice, and the license is still paid. It is a vendor's framing, but we have seen the same shape at clients. The root causes generalize: two systems of record with no tie-breaker, every pipeline loading both so neither goes stale, consumers hard-bound to physical table names so each repointing opens an inconsistency window, and fifteen years of logic in views and procedures rewritten by hand with new bugs. The reframe that fixes it is that this is a consumer-cutover problem, not a data-movement problem. Move consumers behind an abstraction first, validate parity, then swap the storage underneath them.
When the Numbers Work and When They Do Not
The case is strong when most of these are true: the warehouse bill is dominated by ELT and transformation rather than human queries; the same data already exists in two or three paid copies; there is a streaming or ML workload the warehouse handles badly; the total is comfortably above single-digit terabytes; and the team already runs Spark, Flink or Kubernetes in production.
The case is weak when the warehouse mostly serves BI dashboards, the spend is small enough that one engineer's salary exceeds it, nobody on the team has run Spark, or the governance requirements are stricter than the platform team can rebuild. It is also weak when the data silos are an org-chart problem. Iceberg does not fix politics; you will get it implemented three ways with six catalogs. Those teams are better off tuning what they have. Warehouse optimization is unglamorous, but it arrives in weeks and carries no migration risk.
Three architectures share the name "Iceberg lakehouse", and conflating them is the most common source of a bad business case:
| Pattern | Effort | What changes | Saving | Example |
|---|---|---|---|---|
| A: Warehouse keeps the catalog | Weeks | Snowflake-managed or BigLake-managed Iceberg tables. Bytes move to your bucket in open format; the warehouse still owns writes, optimization and governance. External engines get read access | Small. Bytes move, compute does not | The honest default for most enterprises |
| B: Independent REST catalog | Quarters | Polaris, Lakekeeper or Glue owns the tables. Spark and Flink handle ingestion and transformation; the warehouse stays for BI and governed serving | Large, and it comes from compute | New Relic |
| C: Full replacement | Very high | Warehouse decommissioned; open engines serve everything, including BI. A consumer migration, not a data migration | Not the reason to do it | TRM Labs, driven by on-prem |
Most failed migrations are teams that budgeted for A and accidentally attempted C. Every migration that worked in the public record was incremental. There is no successful big-bang in it. The sequence that de-risks the decision:
- Optimize in place. Cut what you can from the warehouse bill first, so the Iceberg comparison is against a fair baseline.
- Land new data in Iceberg. No migration of history. New pipelines write Iceberg on your object storage; the warehouse reads it externally.
- Move one expensive workload. Pick the single ELT job or backfill that burns the most credits and rerun it on Spark or Flink.
- Measure for a full billing cycle. Compute saved, minus maintenance compute, minus the people-hours. If it is not clearly positive, stop here.
- Move consumers behind an abstraction. Views, a semantic layer, or a query gateway, so dashboards do not know which engine answers.
- Move legacy bytes last. Historical data migrates only once the workloads that read it have already moved.
Frequently Asked Questions
Does Apache Iceberg save money? Yes, when the warehouse bill is dominated by ELT, ingestion or duplicate data copies. Public cases report 35-52% lower platform spend from moving that work to Spark or Flink on Iceberg. It does not reduce storage cost, and it adds maintenance and platform costs that can cancel the saving for BI-only workloads.
Is Apache Iceberg worth it for a small team? Usually not below single-digit terabytes or without Spark or Kubernetes experience. The recurring cost of running compaction, a catalog and a compute engine exceeds what a small warehouse bill can give back.
Is Snowflake with Iceberg tables cheaper than native Snowflake tables? Storage moves to your S3 bill at about the same rate. Compute is still charged in Snowflake credits when Snowflake runs the query. The saving appears only when other engines do the heavy work on the same tables.
Iceberg vs Delta Lake, which is cheaper? Neither format is cheaper by itself. Iceberg's broader engine support makes compute arbitrage easier outside Databricks. Our Iceberg vs Delta Lake comparison covers the trade-offs.
What is Iceberg catalog lock-in? The catalog holds the pointer to every table's current metadata plus access control and credential vending. Catalogs share the REST protocol but differ in features, and moving tables between them is a manual, risky operation. The data is portable; the control plane is not.
Key Takeaways
- Apache Iceberg does not make storage cheaper. Snowflake's $23/TB/month and S3's $0.023/GB/month are the same number.
- The savings are compute arbitrage: ELT, ingestion and backfills running on Spark or Flink at instance prices instead of warehouse credits. That is where New Relic's 35-52% and Airbnb's 50%+ came from.
- Most headline speedups (Grab, Shopify, TRM Labs) came from fixing file layout, dropping JSON, or changing query engines alongside the format change. Credit the format for enabling them, not for causing them.
- Budget 10-25% of query compute for table maintenance, plus a production-critical catalog, plus governance you used to get for free.
- The catalog is the new lock-in point. The REST spec makes it survivable, not painless. Pick it early and follow platform gravity.
- Openness cuts both ways. Medidata used Iceberg to move compute into Snowflake and cut its EKS bill by about 80%. The asset is optionality, not the exit.
- Move workloads before bytes. Every successful public migration was incremental; the documented failure mode is a lift-and-shift that never finishes.
If you are trying to work out whether your warehouse bill has enough ELT in it to justify the move, our data engineering consulting team has run this analysis on Snowflake, BigQuery and Databricks platforms and can tell you before you commit a quarter to finding out.
