4.1 Storage Modes & Direct Lake
Key Takeaways
- Import caches a compressed copy in the VertiPaq engine for the fastest queries but needs a scheduled refresh and uses model memory.
- DirectQuery sends every visual interaction to the source as a live query, so data is always current but performance depends on the source system.
- Direct Lake reads Delta/Parquet files in OneLake directly into memory without an import copy, combining import-class speed with near-real-time freshness.
- Direct Lake transparently falls back to DirectQuery when a query cannot be served from memory; fallback queries behave like DirectQuery, not Import.
- Direct Lake on OneLake reads lakehouse Delta tables; Direct Lake on SQL endpoint queries through the warehouse or lakehouse SQL analytics endpoint.
Why Storage Mode Is the First Modeling Decision
In the Implement and manage semantic models domain (25-30% of DP-600), almost every model question starts with one choice: how the model holds its data. The exam tests whether you can match a storage mode to a scenario's freshness, performance, and source requirements rather than just defining the modes.
A semantic model (formerly called a dataset) is the business layer that reports and analysts query with DAX. Each table in the model uses one of three storage modes, and Microsoft Fabric adds a Fabric-native option, Direct Lake, on top of the classic Power BI options.
The Three Storage Modes
Import copies source data into the model and compresses it with the in-memory VertiPaq columnar engine. Queries are extremely fast because everything is resident in memory, but the data is only as fresh as the last refresh, and large models consume capacity memory.
DirectQuery stores no data in the model. Every visual interaction is translated to a live query against the source (warehouse, SQL database, etc.). Data is always current and the model stays small, but query speed is bounded by the source and concurrency, and some DAX is limited.
Direct Lake is unique to Fabric. The model reads the Delta/Parquet files of a lakehouse or warehouse in OneLake straight into memory on demand — no scheduled import copy. You get Import-class query speed with DirectQuery-class freshness, which is why Microsoft positions it as the default for Fabric semantic models.
Direct Lake Framing and Fallback
Two Direct Lake behaviors are heavily tested.
Framing is how Direct Lake decides which version of the Delta data it can serve from memory. A reframe operation updates the model's pointers to the latest committed Parquet files. Until the model is reframed (manually, on a schedule, or by a configured refresh), queries can serve a slightly older snapshot even though OneLake already has newer data.
Fallback happens when a query cannot be answered from the in-memory Direct Lake columns — for example, when data volume exceeds the capacity guardrails or a feature is unsupported. The model silently issues a DirectQuery to the lakehouse or warehouse SQL endpoint instead. Fallback queries inherit DirectQuery performance characteristics, not Import speed. You can set the DirectLakeBehavior property to control whether fallback is automatic, forced, or disabled.
Direct Lake on OneLake vs Direct Lake on SQL Endpoint
A newer DP-600 distinction: Direct Lake on OneLake reads the lakehouse Delta tables directly, supports a broader set of sources, and is the more flexible option. Direct Lake on SQL endpoint routes through the warehouse or lakehouse SQL analytics endpoint, which means it respects SQL-endpoint security and views but can fall back to DirectQuery against that endpoint. Choose Direct Lake on OneLake for maximum performance and Delta-native access; choose the SQL endpoint variant when you must inherit warehouse object-level logic or security.
When to Choose Each
| Requirement | Best mode |
|---|---|
| Source already lands in a Fabric lakehouse/warehouse, need fast and fresh | Direct Lake |
| Data must be live every second from an operational SQL source not in OneLake | DirectQuery |
| Small/medium data, fastest possible visuals, daily freshness acceptable | Import |
| Mix: large fact in DirectQuery/Direct Lake plus small Import dimensions | Composite model |
| Aggressive transformations + complex DAX with no Fabric source | Import |
A team builds a Fabric semantic model over a lakehouse. During a heavy month-end period, some report visuals slow down noticeably while others stay fast, and the model still returns correct data. What is the most likely explanation?
A semantic model uses Direct Lake. New rows were written to the lakehouse Delta table 10 minutes ago, but a report still shows the older totals even though the model is healthy. What should you check first?