3.3 Choose the Right Store: Lakehouse vs Warehouse vs Eventhouse

The Most-Tested Decision on the Exam

Expect multiple scenario questions that hand you a workload and ask which Fabric store to use. The reliable mental model: what does the data look like, who edits it, and which language dominates?

• Lakehouse — open Delta Lake/Parquet tables and files in OneLake. Engineers transform with Spark/notebooks and Dataflow Gen2. Every lakehouse automatically exposes a SQL analytics endpoint that is read-only T-SQL over those tables. Choose it for open-format data, data engineering, ML feature prep, and unstructured/semi-structured files.
• Warehouse — a fully relational, read-write T-SQL store. It supports INSERT/UPDATE/DELETE, multi-table transactions with full ACID guarantees, views, and stored procedures. Choose it for classic relational analytics, dimensional modeling owned by SQL developers, and workloads needing T-SQL DML.
• Eventhouse — built on the KQL engine; optimized for high-volume streaming, telemetry, logs, IoT, and time-series. Queried with KQL (with a limited SQL surface for some operations). Choose it whenever the scenario stresses real-time ingestion and event/time-series analytics.

Decision Table

How Personas Map to Stores

DP-600 often encodes the answer in who does the work. A team of Spark/Python data engineers building Delta tables and feature sets points to a lakehouse. A team of SQL developers writing stored procedures and running nightly DML points to a warehouse. A real-time/operations analyst chasing per-second device metrics points to an eventhouse. When the persona and the language line up, trust that signal over surface details like data volume alone.

Serving Layer: Direct Lake Reads From Both

Because both the lakehouse and the warehouse persist tables as Delta in OneLake, a Power BI semantic model can use Direct Lake mode to read those Delta files directly — no import refresh and no DirectQuery round-trip to a SQL engine. That means your store choice feeds the serving layer regardless of whether you picked lakehouse or warehouse, as long as the data lands as Delta. The eventhouse is the exception: its KQL data is served to real-time dashboards and KQL querysets rather than through a classic Direct Lake import.

On the exam, if a question pairs "fastest BI reads over curated Delta tables" with a store choice, remember that both lakehouse and warehouse qualify and the deciding factor is the write/transform workload, not the read path.

The Read-Only Endpoint Trap

The most common distractor on this topic: assuming the lakehouse SQL analytics endpoint can run T-SQL writes. It cannot — it is read-only over the Delta tables, exposing SELECT, views, and BI connectivity only. To modify lakehouse data you go back to Spark, notebooks, or Dataflow Gen2. If the scenario requires UPDATE/DELETE, multi-table transactions, or stored procedures executed in T-SQL, the correct store is a warehouse.

A second trap: choosing a warehouse for streaming telemetry because it is "a database." High-ingest event and time-series workloads belong in an eventhouse, where the KQL engine and ingestion pipeline are optimized for that pattern. And a warehouse is not an eventhouse: T-SQL relational analytics and KQL telemetry are different engines for different jobs.

Quick Disambiguation

Cross-Store Reality with OneLake

Because lakehouses and warehouses both store data as Delta in OneLake, you can often query across them and reuse data with shortcuts instead of duplicating it — for example, shortcutting a curated warehouse table into a lakehouse for a Spark job. Still, the exam wants the primary store chosen by the dominant workload and language, not "all three." Read the scenario for the load pattern (batch files vs. relational DML vs. streaming) and the persona doing the work, then pick the one store that fits. If a follow-up asks how to share that data with another store cheaply, the answer is usually a shortcut rather than a Copy activity.

Capacity and Compute Notes

All three stores run on the same Fabric capacity (an F-SKU such as F2 through F2048, or a Power BI Premium P-SKU), so they share a pooled pool of capacity units rather than each carrying a separate bill. Practical exam implications: a runaway Spark notebook, a heavy warehouse query, and a high-ingest eventhouse all draw from the same capacity, so right-sizing the store to the workload also controls cost.

A warehouse and a lakehouse SQL endpoint both use the same distributed SQL engine, which is why their T-SQL SELECT performance is comparable — the difference the exam tests is write capability (warehouse read-write, endpoint read-only), not raw read speed. When a scenario complains about a small capacity being exhausted by full nightly reloads, the fix is usually incremental loading or a shortcut, echoing the ingestion topic.