DP-600: Choosing Microsoft Fabric Analytics Stores: Lakehouse, Warehouse, Eventhouse, and Semantic Models

Choose a lakehouse when varied files and tables need Spark-led engineering, a Warehouse when structured analytical data needs a SQL-first relational experience, and an Eventhouse when high-volume event streams need low-latency analysis with Kusto Query Language (KQL). Choose a Power BI semantic model when consumers need governed relationships, measures, hierarchies, and business terminology for reporting. A semantic model normally sits above an analytical store; it is not a substitute for choosing where prepared data belongs.

The decision therefore has two layers. First select the primary data item by data shape, development and query engine, latency pattern, and write requirements. Then decide whether a semantic model should present that data to Power BI and other business consumers. Microsoft Fabric supports combined architectures, so the goal is not to force every workload into one item but to give each layer a clear responsibility.

Architecture Overview

Microsoft's storage guidance distinguishes the items by workload: a lakehouse supports open, flexible data engineering; a Warehouse supports relational SQL analytics; an Eventhouse supports real-time event analysis; and a semantic model supplies business logic for reporting. This is a workload boundary, not merely a choice of user interface.

OneLake is the shared logical data lake for a Fabric tenant. It provides a common storage and discovery foundation across Fabric, but it does not make every item operationally identical. The item still determines which engine is primary, which write patterns are supported, how data is organized, and which consumers receive the most natural experience.

Decision dimension	Lakehouse	Warehouse	Eventhouse	Power BI semantic model
Primary role	Flexible engineering and analytical storage	Curated relational analytics	Real-time event ingestion and analysis	Business-facing analytical layer
Best-fit data	Structured tables plus unstructured or non-tabular files	Structured relational tables, commonly dimensional models	Time-oriented telemetry, logs, and event records	Curated fields, relationships, measures, and hierarchies
Primary engine or language	Apache Spark; read-only T-SQL over Delta tables through the SQL analytics endpoint	T-SQL with relational data definition and manipulation	KQL on KQL databases	Data Analysis Expressions (DAX) and Power BI queries
Latency emphasis	Batch or engineering-led processing, with analytical access to current Delta tables	Governed SQL analytics and business intelligence workloads	Continuous, high-volume ingestion and low-latency exploration	Interactive consumption; source freshness depends on the selected table storage mode
Choose it when	Engineers need files, Delta tables, notebooks, and Spark in one item	SQL teams need a writable, schema-oriented analytical store	Event time, arrival rate, and rapid time-series analysis drive the design	Users need consistent business meaning and reusable calculations

The table identifies a primary fit, not an exclusivity rule. A solution can use a lakehouse to refine data, a Warehouse to serve a dimensional model, an Eventhouse for operational telemetry, and semantic models over one or more curated sources.

Core Components

Lakehouse for Spark-led data engineering

A Fabric lakehouse stores both files and managed Delta tables in OneLake. It is the strongest starting point when engineers need to retain heterogeneous source data, use notebooks or Spark jobs, and progressively refine that data into analytical tables. The lakehouse documentation identifies Apache Spark as its primary development environment while also providing SQL access to Delta tables.

Each lakehouse receives a SQL analytics endpoint. That endpoint lets analysts query Delta tables with Transact-SQL (T-SQL), but its data surface is read-only and does not provide the full write behavior of a Warehouse. This boundary matters: the presence of a SQL endpoint does not turn a lakehouse into a SQL-first relational store.

Choose a lakehouse when one or more of these conditions dominate:

Source data includes files or data that benefits from flexible, code-driven preparation.
Apache Spark, Python, or notebooks are central to transformation and enrichment.
A medallion-style refinement process needs raw, cleansed, and curated data zones.
The team wants Delta tables to serve both engineering and downstream analytical access.

Avoid selecting it solely because some consumers use SQL. If the main authors work in T-SQL, require relational writes, and are building curated star schemas for business intelligence, a Warehouse is usually the clearer primary item.

Warehouse for SQL-first relational analytics

A Fabric Warehouse is an enterprise-scale relational analytical item on the Fabric data-lake foundation. It is designed for structured data, T-SQL development, dimensional models, and governed business intelligence. Unlike a lakehouse SQL analytics endpoint, a Warehouse supports relational data definition and manipulation along with multi-table transactions. The Fabric Data Warehouse overview describes star and snowflake schemas, curated data marts, and governed semantic models as central use cases.

Choose a Warehouse when:

The target is a structured relational model with well-defined tables and schemas.
T-SQL is the team's primary development and query language.
Data preparation or serving logic needs writable relational operations.
Business intelligence consumers need a curated dimensional source with predictable SQL semantics.

A Warehouse does not eliminate the value of a lakehouse. A common architecture uses Spark in a lakehouse for engineering and a Warehouse for the final SQL-managed serving layer. Use that split only when the additional item creates a meaningful ownership or workload boundary; otherwise it adds orchestration, security, and operational overhead without improving the outcome.

Eventhouse for event-driven analytics

An Eventhouse is the primary choice when the workload is organized around continuously arriving events rather than periodically curated business tables. It hosts KQL databases and is designed for high-volume event ingestion and low-latency analysis. Typical data includes telemetry, application or security logs, device signals, and other time-oriented records. Microsoft's Real-Time Intelligence overview positions Eventhouse and KQL at the center of these streaming and real-time analytical scenarios.

Choose an Eventhouse when:

Data arrives continuously and time is a primary analytical dimension.
Analysts need rapid filtering, aggregation, correlation, or anomaly investigation over event data.
KQL is the natural language for the workload.
Operational awareness depends on recent events becoming queryable quickly.

Do not choose Eventhouse merely because a table contains timestamps or because the word “real-time” appears in a requirement. A daily sales fact table with a transaction date can still be a Warehouse or lakehouse workload. Eventhouse becomes the better fit when ingestion velocity, event-time analysis, and low-latency operational questions materially shape the architecture.

Semantic model for business meaning and consumption

A Power BI semantic model organizes analytical data for consumption. It adds relationships, measures, hierarchies, formatting, and business metadata so report authors and users do not have to interpret physical storage structures directly. The semantic-model documentation also makes clear that semantic models connect reporting to Fabric data through storage modes such as Import, DirectQuery, and Direct Lake.

Choose a semantic model when consumers need:

Reusable business measures with consistent definitions.
Relationships and hierarchies that support intuitive analysis.
A curated field list and business vocabulary instead of storage-level objects.
A governed analytical interface shared across reports.

This is usually an additional choice, not a competing store selection. A semantic model can serve data from a lakehouse or Warehouse and can participate in solutions that include real-time data. Selecting its table storage modes is a separate design decision covered in DP-600: Choosing Power BI Semantic Model Storage Modes and Composite Models.

How the Components Work Together

The cleanest Fabric architectures separate responsibilities without creating unnecessary copies. OneLake provides the common data foundation. A lakehouse, Warehouse, or Eventhouse gives data a workload-specific home and engine. A semantic model then supplies a business-facing layer when reports and reusable analytics require one.

Consider three example patterns:

A data engineering team lands varied source files, transforms them with Spark, and publishes Delta tables in a lakehouse. A semantic model exposes approved measures and relationships to report authors.
A business intelligence team loads governed, structured data into a Warehouse and maintains a star schema with T-SQL. A semantic model presents business measures over that dimensional source.
An operations team ingests device telemetry into an Eventhouse and uses KQL for low-latency investigation. Curated outputs can be made available to broader analytical experiences when a stable reporting layer is required.

These are design examples, not mandatory blueprints. The correct boundary depends on who owns each layer, which engine performs the work, how quickly data must be visible, and whether consumers need raw exploration, relational access, event analytics, or standardized business meaning.

Design Considerations

Start with the dominant workload

Begin with the work the primary item must perform most often. If the team primarily transforms files and Delta tables with Spark, start with a lakehouse. If it primarily builds and serves structured relational models with T-SQL, start with a Warehouse. If it primarily ingests and investigates continuous events with KQL, start with an Eventhouse. Add a semantic model when standardized business consumption is part of the requirement.

This approach prevents a secondary access method from driving the architecture. For example, both a lakehouse and Warehouse can support SQL analytics, but only the Warehouse is the SQL-first writable relational choice. Likewise, data from several stores can reach reports, but that does not make the semantic model the system of record for prepared data.

Test the choice across four dimensions

Use four questions to challenge an initial preference:

Data shape: Must the item hold heterogeneous files, relational tables, or event streams?
Engine: Will authors primarily use Spark, T-SQL, KQL, or DAX?
Latency: Is the workload driven by scheduled refinement, interactive SQL analytics, continuous event arrival, or report-query responsiveness?
Consumer: Does the output serve engineers, SQL analysts, operations teams, or business users who need governed measures?

When the answers point to different items, define multiple layers rather than asking one item to mimic every other experience. Record which item owns raw data, curated data, write operations, event analysis, and business definitions. That ownership model is more durable than a tool comparison based only on feature overlap.

Keep downstream decisions separate

Store selection should precede the detailed choice of how data arrives and how a semantic model accesses it. Connection identities, pipelines, transformations, streaming paths, and copy-versus-in-place access are covered in DP-600: Discovering, Connecting, and Ingesting Data in Microsoft Fabric. Import, DirectQuery, Dual, composite-model, and large-model decisions belong to the semantic-model storage architecture layer.

This separation avoids premature optimization. First establish the authoritative analytical item and its engine. Then design movement, transformation, and consumption around that boundary.

Common Mistakes

Treating the four options as peers. A lakehouse, Warehouse, and Eventhouse are workload-specific data items; a semantic model is generally a consumption layer above prepared data.
Choosing by familiar language alone. SQL availability in a lakehouse does not provide the same write-oriented relational experience as a Warehouse, and a timestamp column does not automatically require Eventhouse.
Assuming OneLake removes architectural differences. Shared storage and interoperability do not erase each item's engine, access, and workload boundaries.
Using one item for every workload. Feature overlap can be useful, but forcing batch engineering, relational serving, event analysis, and business semantics into one responsibility creates unclear ownership.
Creating layers without a purpose. Combining items is justified when it separates engines, ownership, latency, or consumers—not simply because the platform permits it.
Designing the semantic model before defining source grain. Measures and relationships depend on reliable, appropriately shaped source tables. Establish the analytical source and its grain before finalizing the business layer.

Certification Relevance

For DP-600, store selection is a design skill that connects data preparation with semantic-model implementation. A candidate should be able to read a requirement, identify its dominant data shape, engine, latency, and consumer, and explain why one item is the primary fit. The DP-600 study guide establishes the current scope across getting data, querying and analyzing data, and implementing semantic models.

Useful preparation focuses on boundaries rather than memorized slogans. Be able to explain why a SQL analytics endpoint does not make a lakehouse equivalent to a writable Warehouse, why event-time operational analysis differs from ordinary timestamped relational data, and why a semantic model adds business meaning instead of replacing the underlying analytical store.

Conclusion

Choose a lakehouse for flexible Spark-led engineering over files and Delta tables, a Warehouse for structured T-SQL relational analytics, and an Eventhouse for high-volume, low-latency event analysis with KQL. Add a Power BI semantic model when business consumers need governed relationships, measures, hierarchies, and terminology.

The strongest decision starts with the dominant workload and tests it against data shape, engine, latency, and consumer needs. When those dimensions point to more than one item, use a layered architecture with explicit ownership rather than treating overlapping features as proof that the items are interchangeable.