Lakehouse vs. warehouse in 2026: a decision framework that actually answers the question

Most enterprises above $500M in revenue run at least one cloud data warehouse. A growing share also run a lakehouse. Few can articulate, with any precision, why they chose one over the other for any given workload, or how they ended up operating both with a full ETL copy running between them.

The distinction matters in 2026 more than it did three years ago because the cost gap between correct and incorrect architecture decisions has widened. Storage is cheap. Compute is not. Query engines have diverged sharply in what they optimize for, and the organizational cost of migrating a poorly chosen platform climbs every quarter that pipelines accumulate on top of it.

We have run this analysis across roughly a dozen client engagements over the past two years. What follows is the decision framework we actually use, not the one vendors publish.

Why the debate keeps producing bad decisions

The warehouse versus lakehouse debate generates bad outcomes for a specific reason: teams treat it as a technology choice when it is fundamentally a question about workload types, team composition, and cost tolerance.

Vendors frame it as technology because they want you to pick sides. Databricks publishes benchmarks showing lakehouse performance at parity with warehouses. Snowflake publishes benchmarks showing the reverse. Both sets of benchmarks are real. Both are also optimized for the workload the respective vendor excels at. A TPC-DS run on Snowflake tells you nothing useful about how that platform handles 200 concurrent data science notebooks writing to shared Parquet files.

The confusion compounds because both platforms have absorbed features from each other's original value proposition. Snowflake added Iceberg table support in 2023, allowing it to write open-format tables into your own object storage. Databricks SQL closed much of the latency gap on standard business intelligence queries. The product boundaries blurred, but the underlying architectural tradeoffs did not disappear.

What actually changed between 2020 and 2026

Three structural shifts define the current landscape.

First, Apache Iceberg became the dominant open table format for net-new lakehouse builds outside the Databricks ecosystem. Iceberg's table specification handles schema evolution, hidden partitioning, and time travel in ways the original Parquet-based data lake could not. The practical result is that lakehouse tables now behave more like database tables, with ACID guarantees and consistent reads across concurrent writers.

Second, compute costs became the dominant variable. Object storage runs approximately $0.023 per GB per month for S3 Standard in us-east-1. Warehouse storage, once you factor in proprietary formats and managed compute, typically runs two to three times higher for equivalent data volumes. At ten terabytes of hot analytical data, the difference is noise. At 500 terabytes, it is a material budget line.

Third, machine learning and AI workloads grew large enough to force the question. Business intelligence dashboards and financial reporting are warehouse-native workloads. Model training, vector search, and feature engineering are lakehouse-native workloads. Any enterprise with a serious ML program will have both types, and a platform choice that ignores which workload represents the larger share of future demand will produce the wrong answer.

The five variables that should drive your decision

We evaluate five dimensions when a client faces this choice.

Query latency requirements. Business-critical dashboards served to executives expect sub-300ms response on complex aggregations over large fact tables. Warehouses built on columnar storage and aggressive caching, such as Snowflake's result cache or Redshift's materialized views, are engineered for exactly this profile. Lakehouse query engines including Trino, Spark SQL, and DuckDB have improved substantially but still carry higher cold-start latency for interactive workloads with no warm cache. If your primary consumer is a finance team expecting sub-second dashboards, the warehouse wins.

Data variety and schema stability. Warehouses enforce schema at write time. This is an advantage when your data is structured and your producers are disciplined; it becomes a bottleneck when you ingest semi-structured event streams, third-party SaaS extracts, or raw application logs where the schema drifts on someone else's release cycle. Lakehouses handle schema variety and evolution far more gracefully. If more than 30% of your ingested data arrives in semi-structured form, or if schema changes are a recurring friction point between platform and producer teams, the lakehouse architecture is better suited.

Team composition and SQL fluency. This is the variable most often ignored. Lakehouse platforms assume a team comfortable with Python, PySpark, and distributed compute primitives. If your data team is primarily SQL analysts, migrating to a Spark-native platform adds months of retraining and a higher ongoing support burden. The right platform is partly a function of the team you have today, not only the workload you plan to run.

ML and AI workload share. If your data platform will primarily serve business intelligence, with occasional exploratory analysis, a warehouse is often simpler to operate and less expensive at moderate scale. If model training, batch inference, or feature store workloads constitute more than 20% of your compute spend, the lakehouse architecture pays for itself through better toolchain integration and lower data movement costs between storage and training compute.

Cost structure at your data volume. Below roughly 10 TB of hot analytical data, cost differences are small enough that platform preference and team familiarity should dominate the decision. Above 50 TB, the storage and compute cost structure diverges enough to warrant a careful model. Above 500 TB, the decision favors lakehouse for most workloads, because no warehouse pricing model is economical at that volume for anything other than the most latency-sensitive queries.

The counter-take we will defend

Conventional advice in 2026, as surfaced by most vendor sales cycles, frames the lakehouse as the modern default and the warehouse as a legacy holdout. We disagree with that framing.

Warehouse technology has not stood still. Snowflake's Cortex ML functions allow model serving directly inside the warehouse. BigQuery's BQML has offered in-database machine learning since 2018. Redshift Serverless eliminates most of the capacity planning overhead that made warehouses operationally expensive for variable workloads. The warehouse has absorbed enough of the lakehouse value proposition that for a large class of enterprise workloads, structured reporting with occasional ML, it remains the simpler and lower-risk architecture.

The cases where we recommend lakehouse as the primary platform rather than a secondary system running alongside a warehouse are narrower than vendor marketing suggests. Heavy ML workloads, genuine petabyte-scale data volumes, and the need to share data across business units without copying it are real and important use cases. They are not universal. Recommending a lakehouse migration to a 50-person analytics team running structured finance and operations reporting on a well-tuned warehouse is a recipe for 18 months of disruption and no improvement in the metrics that matter to the CFO.

When lakehouse is the right default

Four conditions taken together push us toward recommending a lakehouse-first architecture: more than 20% of platform compute going to ML or AI workloads; a significant volume of semi-structured or unstructured source data; a data science team larger than three full-time engineers; and a desire to avoid vendor lock-in on storage format.

Open table formats are the clearest expression of why that last condition matters. A table written by Databricks, stored in Iceberg format in S3, can be read by Trino, by Snowflake's Iceberg connector, or by a local DuckDB query in a Python script. The compute layer becomes swappable. That optionality has real value for organizations that have been burned by proprietary warehouse formats complicating migrations or blocking new tooling adoption.

One pattern we see frequently: a team starts a lakehouse migration to support ML workloads and discovers twelve months in that the finance team still runs all reporting against the old warehouse, because the lakehouse query engine's interactive latency does not meet their SLA. The answer is not to force-fit one platform for all users. Run both, connected by shared Iceberg tables in object storage, and let each compute layer serve the workload it is optimized for.

The open-format convergence changes the math

The most important structural shift in 2026 is that the warehouse and lakehouse are no longer fully separate ecosystems. Both Snowflake and Databricks can now read and write Apache Iceberg tables stored in your own S3 or GCS buckets. The architecture choice is increasingly about the compute layer, not the storage layer.

The practical implication: organizations that anchor their storage strategy on Iceberg in object storage and then choose compute engines by workload type have more flexibility than organizations that allowed a single vendor to own both layers. A Snowflake virtual warehouse handles the finance team's sub-300ms dashboard queries. A Databricks cluster handles the ML team's feature engineering pipelines. Both read from the same Iceberg tables in S3. The storage is shared; the compute is specialized.

We are running this pattern with several clients today. The operational overhead is lower than managing a full ETL copy between two separate platforms, and the cost of maintaining both compute layers is offset by right-sizing each one for its actual workload rather than over-provisioning a single platform to cover both.

What to do in the next 90 days

1. Audit your workload mix. Measure what percentage of your current platform compute goes to business intelligence queries versus ML or AI training and inference. If the split is below 15% ML, a warehouse is likely the right primary platform. If it exceeds 30%, assess whether your warehouse can serve that workload economically over the next two years.

2. Classify your source data by structure. If fewer than 10% of your ingested data sources arrive in semi-structured format, your warehouse's schema enforcement is an advantage worth keeping. If that figure is above 30%, evaluate whether the warehouse's rigidity is costing you more than the latency benefit is returning.

3. Run a compute cost model at your actual data volume. Take your current monthly platform spend and model it against S3 storage priced at $0.023 per GB per month plus a lakehouse compute layer sized to your actual query load. At volumes below 10 TB, the result will rarely justify a migration. At 50 TB and above, the difference becomes significant.

4. Pilot Iceberg tables before committing to a migration. If you run Snowflake today, Iceberg table support allows you to write to open-format storage in your own account without migrating off the platform. This is a low-risk way to test the open-format model and preserve optionality without committing to a full architecture change. If you run Databricks, the equivalent test is confirming that Databricks SQL meets your finance team's p95 query latency before you decommission the warehouse.

5. Defer migration for stable, structured business intelligence workloads. If your warehouse is running structured reporting reliably and your team is SQL-native, no business case exists for disrupting that in the name of modernization. Direct new workloads, particularly ML pipelines and semi-structured data ingestion, toward a lakehouse layer. Let the two coexist over shared Iceberg tables until the balance of workloads justifies revisiting the primary platform decision with real data rather than vendor forecasts.