The lakehouse vs warehouse debate has aged badly because most of it never named the actual change. The thing that shifted is not “we put a query engine on top of object storage” — Presto did that a decade ago. The thing that shifted is that the file layout itself became a stable, versioned, multi-engine API. Iceberg and Delta Lake are not storage formats with extra features bolted on. They are contracts that decouple the data from any single engine that reads or writes it.
Whether that contract is worth the operational surface it introduces is the only question that matters. The answer depends entirely on how many engines you actually need to point at the same tables.
The shift, stated plainly
A warehouse owns its storage. Snowflake’s micro-partitions, BigQuery’s Capacitor format, Redshift’s columnar blocks — these are internal implementation details. You cannot point another engine at them. The warehouse is both the storage layout and the only legal reader.
An open table format inverts that. The table is a manifest of Parquet files plus metadata describing schema, partitioning, snapshots, and statistics — all of it readable by anything that speaks the format. Spark, Trino, DuckDB, Snowflake, Databricks SQL, Flink, Athena, and a growing list of others can transact against the same physical bytes without copying them.
That is the file-format-as-API revolution. The Parquet files are the storage. Iceberg or Delta is the API. Compute becomes pluggable.
Where it actually pays off
You have more than one compute engine and that is not a temporary state. This is the only argument that holds up under scrutiny. If your batch pipelines are Spark, your ad-hoc analytics is Trino or DuckDB, your streaming is Flink, and your BI is something that prefers a SQL warehouse — the lakehouse pattern lets all of them transact on the same tables. No CDC out of the warehouse, no nightly mirroring jobs, no “which copy is fresh.” This is genuinely transformative for organizations whose workload mix is heterogeneous and stable.
You have ML training that needs the same data as analytics. Feature stores are largely a workaround for the warehouse’s inability to expose its data to training infrastructure cheaply. Iceberg or Delta over object storage collapses that — the same partitioned tables feed both your dbt models and your training pipelines, with time-travel snapshots giving you reproducibility for free.
You are doing genuine multi-petabyte work. Warehouse pricing curves bend painfully past a certain scale. The lakehouse pattern lets you separate hot from cold cleanly, run the heavy compute on spot instances, and avoid paying warehouse rates for storage you query once a quarter.
You need vendor optionality as a strategic posture. If “we could move our compute to a different vendor in a quarter” has actual board-level value — pending acquisitions, regulatory pressure, contract renegotiations — the lakehouse pattern is one of the few infrastructure choices that makes that real instead of theoretical.
Where it just adds operational surface
You are SQL-dominant and have one engine. If 90% of your workload is dbt models and BI dashboards, and your only compute is Snowflake or BigQuery, an Iceberg layer underneath buys you almost nothing and costs you a meaningful chunk of platform team attention. You now own table maintenance — compaction, snapshot expiration, orphan file cleanup, manifest rewriting — that the warehouse used to do invisibly. The “open” part of open table formats is irrelevant when you have nothing to open them with.
Your data volume is under ~50TB. At this scale, warehouse pricing is rarely the binding constraint. The thing that’s slow is your model build times, your CI/CD, your governance review cycle — none of which a storage format change addresses. Lakehouse migrations at this scale are almost always solving the wrong problem.
You don’t have a platform team that can own table maintenance. Iceberg and Delta both require ongoing housekeeping. Skip it and your query times degrade silently as small-file counts and snapshot history accumulate. Warehouses hide this work; lakehouses make it yours. If you don’t have at least one engineer who can credibly own that operational surface, the abstraction is leaking faster than it’s helping.
You think you’ll need it eventually. This is the most common failure mode. The lakehouse pattern is not a hedge — it’s an active operational commitment. Adopting it before you have the workload diversity to justify it means you pay the cost now for benefits you may never collect.
How to tell which side you’re on
Three questions, answered honestly:
- How many distinct compute engines do you operate against your warehouse data today, and is that set growing? If the answer is one and stable, the lakehouse pattern is solving a problem you don’t have.
- Do you have a named owner for table maintenance — compaction, vacuum, snapshot policy — with capacity budgeted for it? If not, the warehouse will keep doing this work better than you will.
- Is your data volume curve bending faster than your warehouse cost curve? If your warehouse spend is growing roughly linearly with revenue, the cost argument for lakehouse is weaker than it looks.
If you answered yes-yes-yes, the file-format-as-API shift is real leverage for you and worth the operational tax. If you answered no to any of them, the warehouse is still the right default. The lakehouse pattern rewards a specific shape of workload. Forcing your shape to match the pattern is how data teams end up with two years of migration work and a platform that’s harder to operate than what they replaced.
The abstraction is genuinely powerful. It is not universally applicable. Knowing which side of that line you’re on is the entire game.