ARCHITECTURE · Mar 2026
Trusted by industry leaders
A decade after the lakehouse first showed up in vendor decks, the architectural debate is mostly settled. The engagement-level decision still isn't.
Every quarter or two, a leadership team asks me whether they should build a lakehouse. They have read the analyst reports. They have seen the diagrams. They are not asking what a lakehouse is. They are asking whether it is the right answer for them, on this Tuesday in this country with this set of source systems and this team.
The honest answer is: usually yes, sometimes no, and the deciding factor is rarely the one in the marketing material.
The original case for the lakehouse was never about cost or performance — both were arguable depending on the workload. It was about storage neutrality. The promise: keep your data in open formats (Parquet, Delta, Iceberg) on cheap object storage, and let any compute engine read it. No more re-ingestion when a new tool comes along.
This matters more in some organizations than others. If your data team is small, your tooling stable and your workloads narrow, the lakehouse buys you flexibility you may never use. If your team is large, your tooling churning, and your workloads cover BI, ML, streaming and ad-hoc analysis simultaneously, the storage-neutrality dividend compounds quickly.
For organizations whose primary analytical workload is well-defined finance and operational reporting, against well-understood relational sources, with a small number of consumers — Snowflake, Synapse Dedicated Pools, or BigQuery still win on time-to-value, governance simplicity and the ability to hire experienced people.
The "we'll need ML someday" argument is real but often overweighted. Many organizations spend years building a lakehouse for an ML roadmap that arrives smaller and later than planned, while paying daily complexity tax.
Three questions, in order:
1. Will you have multiple analytical engines? If your only consumer is Power BI and a handful of stored procedures, you don't need storage neutrality. A warehouse is fine.
2. Will you have data-science or ML workloads against the same data as your BI? If yes, the lakehouse pattern earns its keep — you stop maintaining two copies of the truth.
3. Do you have, or are you committed to hiring, the operational maturity? Lakehouses are more powerful and more demanding. They reward teams that have invested in DataOps, schema management and observability. They punish teams that haven't.
For most enterprises in the DACH region we work with, the answer is hybrid. A lakehouse on Microsoft Fabric or Databricks for the broad analytical estate, with a curated warehouse layer (Snowflake, Synapse, or Fabric Warehouse) for the regulated, finance-grade workloads. Storage neutrality where flexibility matters, governed serving where consistency matters.
The vendor space has converged on this pattern. Microsoft Fabric ships it as a single product. Databricks does it through Unity Catalog and SQL Warehouses. Even Snowflake supports Iceberg natively now. The architectural debate is over. The engagement-level decision remains.
A 2024 Databricks survey of 1,600 data teams found that 73% now run some form of lakehouse architecture, up from 41% in 2021. Yet in the same survey, 38% of respondents reported their warehouse workloads running on Databricks SQL or Snowflake alongside a lakehouse — not instead of one. The "either/or" framing is obsolete. The practical question is where you draw the line.
Storage cost is real but frequently overstated in vendor materials. At current Azure pricing, Data Lake Storage Gen2 costs roughly €0.018 per GB/month for the hot tier. Synapse Dedicated SQL Pool starts at around €5.80 per DWH unit per hour. For a 100 TB analytical estate, the difference in storage alone is meaningful — but compute, governance and operational overhead typically dwarf raw storage in total cost of ownership calculations.
Delta Lake (Databricks), Apache Iceberg and Apache Hudi have materially shifted the lakehouse value proposition since 2022. ACID transactions, schema evolution and time travel — previously only available in managed warehouses — now work reliably on object storage. Microsoft Fabric's OneLake uses Delta Parquet natively. Snowflake added Iceberg support in 2023. This convergence means the storage neutrality dividend is now available without sacrificing governance.
In practice, we see three patterns that consistently work well: (1) Full lakehouse on Fabric or Databricks for organizations with mixed BI, ML and streaming workloads. (2) Warehouse (Snowflake, Synapse, BigQuery) for organizations whose entire analytical workload is structured SQL against well-understood relational sources. (3) Hybrid: Delta Lake on ADLS for raw and silver layers, Fabric Warehouse or Snowflake for the curated gold layer consumed by Power BI. Pattern 3 is the most common outcome of our architecture reviews.
In our experience across 80+ enterprise data engagements, the decision between lakehouse and warehouse accounts for maybe 20% of project outcomes. The remaining 80% is determined by data quality discipline, ownership models, and whether the team has the operational maturity to maintain schema contracts over time. We have seen well-architected lakehouses fail because no one owned the schema registry, and simple SQL warehouses succeed because the finance team reviewed data quality metrics every Monday.
First conversation is always free.