Skip to main content

By Errin O'Connor, Founder & Chief AI Architect, EPC Group

HomeBlogMicrosoft Fabric
Back to BlogMicrosoft Fabric
EO
Errin O'Connor
Founder & Chief AI Architect
May 4, 2026
13 min read
Microsoft FabricLakehouseWarehouseEventhouseArchitectureOneLake
Fabric Lakehouse vs Warehouse vs Eventhouse: Enterprise Decision Matrix with Architecture Diagrams
13 min readPublished May 4, 2026

Key Takeaways

  • TL;DR.
  • Executive Summary.
  • The Three Experiences.
  • Decision Matrix.
  • Common Hybrid Patterns.
  • Architectural Considerations.
On this page10 sections

TL;DR

  • Microsoft Fabric offers three primary analytical storage experiences: Lakehouse (Delta-based medallion architecture with Spark), Warehouse (T-SQL columnar warehouse with full ACID), and Eventhouse (KQL Database for time-series and streaming). All three store data in OneLake in Delta format.
  • The choice is workload-driven, not preference-driven. Each experience optimizes for specific patterns. Most enterprises use all three across different workloads.
  • Lakehouse wins for medallion-architecture batch analytics, Spark-fluent teams, and data engineering at scale.
  • Warehouse wins for SQL-fluent teams, traditional dimensional modeling, and workloads requiring stored procedures, T-SQL views, and full ACID semantics.
  • Eventhouse wins for time-series, log, and streaming data with KQL queries.
  • Hybrid patterns are typical: data engineering in Lakehouse, dimensional modeling in Warehouse, streaming in Eventhouse, all surfaced through Power BI semantic models.
  • This guide details the decision matrix, the hybrid patterns, and the architectural considerations.

Executive Summary

A common mistake in Microsoft Fabric architecture is to choose between Lakehouse, Warehouse, and Eventhouse as if they are competing products. They are not. They are different optimizations for different workload patterns, and most enterprise architectures use all three.

The Lakehouse experience suits Spark-fluent data engineering teams working on medallion-style analytics. The Warehouse experience suits SQL-fluent teams building traditional dimensional models with stored procedures and views. The Eventhouse experience suits time-series and streaming workloads with KQL queries.

All three persist data in OneLake in Delta format, so data can be shared across experiences without duplication. A Lakehouse-engineered Silver table can be queried from Warehouse via shortcuts, summarized into Eventhouse for time-series analysis, and surfaced through Power BI semantic models. The architecture is about which experience owns which workload, not about picking a single experience.

This guide details the decision framework, the hybrid patterns, and the implementation considerations.

The Three Experiences

Lakehouse

The Lakehouse experience provides:

  • Apache Spark for data engineering with notebook-based authoring.
  • Delta-based tables organized in the medallion pattern (Bronze raw, Silver cleansed, Gold curated).
  • SQL endpoint for querying lakehouse data from T-SQL tools.
  • Schema evolution native to Delta.
  • Python, Scala, R, SQL authoring options.

Lakehouse is the right primary experience for teams that:

  • Have data engineering expertise in Spark.
  • Build data pipelines in the medallion pattern.
  • Process large volumes through complex transformations.
  • Use Python/Scala for data engineering productivity.

Warehouse

The Warehouse experience provides:

  • T-SQL authoring with the full surface familiar to SQL developers.
  • Stored procedures, views, functions as first-class objects.
  • Full ACID semantics including multi-statement transactions.
  • Columnar storage in Delta format with V-Order optimization.
  • SQL-native CI/CD through SQL Server Management Studio, Azure Data Studio, and SQL projects.

Warehouse is the right primary experience for teams that:

  • Have SQL expertise as their primary skill profile.
  • Build dimensional models with traditional SQL patterns.
  • Require stored procedure-based business logic.
  • Need traditional T-SQL tooling.

Eventhouse (KQL Database)

The Eventhouse experience provides:

  • KQL (Kusto Query Language) for time-series and event-data queries.
  • Streaming ingestion through Eventstream.
  • High-cardinality time-series storage with appropriate indexing.
  • Geospatial query support.
  • Full-text search capabilities.
  • Materialized views for pre-aggregated query patterns.

Eventhouse is the right primary experience for:

  • Time-series data (telemetry, telematics, monitoring).
  • Streaming workloads with sub-minute query latency requirements.
  • High-cardinality event data.
  • Log and observability data.

Decision Matrix

Workload pattern Lakehouse Warehouse Eventhouse
Batch ETL with complex transformations Best OK No
Traditional dimensional modeling OK Best No
Time-series data OK OK Best
Streaming ingestion <5 min latency OK No Best
Stored procedures and views No Best No
Python/Spark-based data science Best No OK
SQL-native team OK Best OK (with KQL learning)
Spark-native team Best OK OK (with KQL learning)
Complex multi-statement transactions No Best No
High-cardinality event data OK OK Best
Mixed batch and streaming Hybrid Hybrid Best for stream
Power BI semantic-model source OK Best OK (specific patterns)

Common Hybrid Patterns

Pattern A: Lakehouse-Centric

For Spark-fluent data engineering teams:

  1. Lakehouse Bronze captures raw data.
  2. Lakehouse Silver cleans and conforms.
  3. Lakehouse Gold provides analytical-ready tables.
  4. Warehouse (optional) is used as a query layer for SQL-tooling access.
  5. Eventhouse is used for streaming workloads not appropriate for batch.

Pattern B: Warehouse-Centric

For SQL-fluent teams:

  1. Warehouse is the primary analytical store with traditional dimensional modeling.
  2. Lakehouse is used for upstream data engineering (Bronze/Silver) before loading to Warehouse.
  3. Eventhouse is used for streaming where applicable.

Pattern C: Eventhouse-Centric

For workloads that are primarily streaming:

  1. Eventhouse is the primary store for streaming and time-series data.
  2. Lakehouse is used for batch analytics complementing the streaming surface.
  3. Warehouse may be used for dimensional reporting alongside the streaming experience.

Pattern D: Tri-Hybrid

The most common Fortune 500 pattern uses all three:

  1. Lakehouse for data engineering pipelines.
  2. Warehouse for SQL-developer-friendly analytical surfaces and traditional dimensional models.
  3. Eventhouse for streaming and time-series workloads.
  4. OneLake shortcuts allow data sharing across the three without duplication.
  5. Power BI semantic models consume from all three depending on the use case.

Architectural Considerations

OneLake Shortcuts

Shortcuts provide zero-copy data sharing between the three experiences. A Lakehouse-engineered Gold table can be shortcut-ed into Warehouse for SQL querying or into Eventhouse for time-series enrichment. The data exists once; multiple experiences access it.

V-Order Optimization

V-Order (Microsoft's write-time optimization for Parquet) applies to all three experiences. Data written by Lakehouse, Warehouse, or Eventhouse experiences gets V-Order by default. Data written by external tools (Databricks, Synapse Spark) may not have V-Order.

Capacity Sharing

All three experiences share the Fabric F-SKU capacity. Capacity-consumption patterns differ:

  • Lakehouse Spark workloads consume during job execution.
  • Warehouse workloads consume during query execution.
  • Eventhouse workloads consume continuously (streaming ingestion + query).

Capacity planning should account for all three.

Source Control and CI/CD

Each experience has its own development tooling:

  • Lakehouse notebooks and pipelines.
  • Warehouse SQL projects with database deployment.
  • Eventhouse KQL scripts and Eventstream definitions.

A coherent enterprise CI/CD pattern uses Git as the source-of-truth across all three with experience-specific deployment pipelines.

Governance

Microsoft Purview applies across all three:

  • Sensitivity labels propagate through Lakehouse, Warehouse, and Eventhouse derived items.
  • Data lineage covers data flow across the three experiences.
  • Access controls are consistent through OneLake domain-level governance.

Implementation Considerations

Skill profile assessment

Before choosing the primary experience, assess the team's skill profile:

  • Spark + Python developers gravitate to Lakehouse.
  • T-SQL developers gravitate to Warehouse.
  • Operations and time-series analysts gravitate to Eventhouse.

The "right" experience for a workload may not be the one the team is fastest with. The trade-off is implementation velocity vs long-term operational fit.

Migration considerations

For enterprises migrating from existing Azure Synapse or Databricks environments:

  • Synapse Dedicated SQL Pools typically migrate to Fabric Warehouse.
  • Synapse Spark Pools typically migrate to Fabric Lakehouse or remain in Synapse Spark via shortcuts.
  • Azure Data Explorer workloads migrate to Eventhouse (same KQL engine).
  • Databricks workloads may stay in Databricks with OneLake shortcuts, or migrate to Lakehouse Spark.

The migration path is workload-by-workload, not all-or-nothing.

Common Pitfalls

  1. Choosing one experience for all workloads. The experiences are complementary; force-fitting all workloads to one creates friction.
  2. Skipping the skill-profile assessment. The team's primary skill determines the productive choice for shared workloads.
  3. Not using shortcuts. Duplicating data across experiences wastes storage and creates synchronization headaches.
  4. Treating Eventhouse as just storage. Eventhouse + KQL is purpose-built for time-series; using it as a generic store under-utilizes the value.
  5. Mixing Warehouse and Lakehouse tables without explicit governance. Without domain-level governance, the architecture becomes opaque.
  6. Forgetting capacity allocation. All three share Fabric capacity; sizing requires consideration of all three workloads.

Frequently Asked Questions

What is Microsoft Fabric Lakehouse?

Microsoft Fabric Lakehouse is the Apache Spark-based analytical experience in Fabric. It provides notebook-based authoring, Delta-based tables organized in the medallion pattern, Python/Scala/R/SQL authoring, and integrates with Power BI for analytics consumption.

What is Microsoft Fabric Warehouse?

Microsoft Fabric Warehouse is the T-SQL-based analytical experience in Fabric. It provides stored procedures, views, functions, full ACID semantics, columnar Delta storage with V-Order, and SQL-native tooling support.

What is Microsoft Fabric Eventhouse?

Microsoft Fabric Eventhouse is the time-series and streaming-data experience in Fabric. It uses KQL (Kusto Query Language) for queries, supports streaming ingestion through Eventstream, and provides geospatial and full-text search capabilities.

When should I choose Lakehouse over Warehouse?

Choose Lakehouse when your team is Spark-fluent, when your workload is medallion-architecture batch analytics with complex transformations, or when you need Python/Scala authoring for data engineering. Choose Warehouse when your team is SQL-fluent or when you need stored procedures and traditional dimensional modeling.

Can I use Lakehouse and Warehouse together?

Yes. Common pattern: Lakehouse for data engineering (Bronze/Silver), Warehouse for the analytical layer (Gold) with dimensional modeling and SQL-tooling support. OneLake shortcuts enable zero-copy data sharing between the two.

Can I use Eventhouse for batch analytics?

Eventhouse can store batch data but is optimized for time-series and streaming. For pure batch workloads, Lakehouse or Warehouse is typically the better fit.

How do I migrate from Azure Synapse Dedicated SQL Pool?

Synapse Dedicated SQL Pool workloads typically migrate to Fabric Warehouse. The migration involves schema migration, stored procedure conversion, ETL pipeline migration, and security model alignment. Microsoft provides documented migration patterns.

How do I migrate from Azure Databricks?

Databricks workloads can stay in Databricks with OneLake shortcuts (preserving the Databricks investment), or migrate to Lakehouse Spark for tighter Fabric integration. The decision depends on Databricks-specific feature dependencies and team skill profile.

Can I migrate from Azure Data Explorer to Eventhouse?

Yes. Eventhouse uses the same KQL engine as Azure Data Explorer. The migration preserves queries, schema, and most operational patterns. Specific feature parity should be verified against the current Eventhouse documentation.

How does V-Order optimization apply across the three experiences?

V-Order is enabled by default for Delta tables written by Lakehouse, Warehouse, and Eventhouse. Tables written by external tools may not have V-Order; explicit OPTIMIZE operations can apply V-Order to existing tables.

What is the capacity-consumption pattern across the three?

Lakehouse Spark consumes during job execution. Warehouse consumes during query execution. Eventhouse consumes continuously due to streaming ingestion. Capacity planning should account for all three patterns.

How does Power BI integrate with each experience?

Power BI semantic models can consume from all three experiences via Direct Lake, DirectQuery, or Import modes. The choice depends on the workload pattern (large volumes favor Direct Lake; complex queries favor Import; real-time freshness favors DirectQuery or Eventhouse).

Are all three experiences available in GCC and GCC High?

Availability varies by region and feature. Verify the current Microsoft Fabric for US Government documentation for the specific tenant.

How does EPC Group support multi-experience Fabric architectures?

EPC Group works with enterprises on Fabric architecture spanning all three experiences. The standard engagement is 24-26 weeks for substantial implementations. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct multi-experience Fabric implementation experience.

What is the cost difference between the three experiences?

All three consume Fabric F-SKU capacity. The cost depends on the workload pattern, not on the experience choice per se. Spark workloads typically consume more capacity per unit of data processed; Warehouse queries are typically efficient; Eventhouse's continuous ingestion is a fixed-cost baseline plus query consumption.

Next Steps

If your enterprise is designing a Fabric architecture or migrating from Synapse/Databricks/ADX, the practical next steps:

  1. Inventory current workloads by pattern (batch ETL, dimensional modeling, streaming, time-series).
  2. Map each workload to its optimal Fabric experience.
  3. Assess team skill profile for primary experience choice.
  4. Design the hybrid architecture with shortcuts.
  5. Engage a partner with deep Fabric architecture experience.

EPC Group has been delivering enterprise Microsoft consulting since 1997 — in its 30th year — and is Microsoft Solutions Partner with the core designations. We were historically the oldest continuous Microsoft Gold Partner in North America through the program's retirement. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct Fabric architecture experience across Lakehouse, Warehouse, and Eventhouse implementations. To discuss your Fabric architecture, contact EPC Group for a 30-minute discovery call.

Share this article:
EO

Errin O'Connor

Founder & Chief AI Architect

Microsoft Press bestselling author with enterprise consulting experience since 1997.

View Full Profile

Need Help with Microsoft Fabric?

Our team of experts can help you implement enterprise-grade microsoft fabric solutions tailored to your organization's needs.

Related EPC Group Services

AI assistant — not human