Direct Lake Mode
Fabric's recommended storage mode in depth. Configuration, fallback behavior, OneLake vs SQL endpoints, and performance best practices.
Direct Lake in depth
Think of Direct Lake as reading a book from a shelf right next to you.
Import copies the book to your desk (fast to read, but your copy gets outdated). DirectQuery reads from the library across town (always the latest edition, but slow because of travel). Direct Lake puts the shelf right next to your desk — you read the latest version instantly without copying it.
This module explains the mechanics: how the engine reads Delta files, what happens when it cannot (fallback), and how to choose between reading from the lakehouse or the warehouse SQL endpoint.
How Direct Lake reads data
The read cycle
- A DAX query arrives (from a visual, API, or DAX query tool)
- The engine checks if the required column is already in memory (cache hit)
- If not cached, the engine reads the column from the Delta Parquet file in OneLake
- The data is loaded into VertiPaq format (compressed columnar) in memory
- The query executes at in-memory speed
- The engine watches the Delta transaction log — when a new version appears, it invalidates the cache
Framing
The process of loading data from Parquet into VertiPaq is called framing. A “frame” represents a snapshot of the Delta table at a specific version. When the table is updated (new data appended, rows modified), the engine creates a new frame.
You can trigger a manual frame update by calling refresh on the semantic model — but unlike Import mode, this is fast because it only reads the changed Delta log, not the entire dataset.
Direct Lake fallback
When Direct Lake cannot serve a query in its normal mode, it falls back to DirectQuery:
What triggers fallback?
| Trigger | Description |
|---|---|
| Column exceeds memory | A single column is too large to load into available capacity memory |
| Row count exceeds guardrails | The table exceeds the max row count for the capacity SKU |
| Unsupported data type | The Delta table contains a type not supported by VertiPaq |
| Too many columns | The model references more columns than the SKU allows |
| Parquet row group size | Parquet files with very large row groups may cause timeout |
Fallback behavior settings
| Setting | Behavior |
|---|---|
| Automatic (default) | Seamlessly falls back to DirectQuery — queries continue but are slower |
| Disabled | Queries FAIL instead of falling back — guarantees Import-speed or nothing |
When to disable fallback
- When you guarantee consistent dashboard performance (no slow surprises)
- When you want immediate alerts that the model exceeds capacity limits
- In production dashboards where query speed is critical
Exam tip: Fallback questions
The exam may describe a scenario where a Direct Lake model suddenly becomes slower. The expected analysis:
- Check if fallback was triggered (look at the DirectQuery counter in usage metrics)
- Identify the cause (column too large, row count exceeded guardrails)
- Fix: OPTIMIZE Delta tables (reduce file count), increase capacity SKU, or reduce model scope
If the question asks “how to ensure queries never fall back?”, the answer is: disable fallback and ensure the model fits within capacity limits.
Direct Lake on OneLake vs Direct Lake on SQL endpoints
The exam specifically tests this choice:
| Source | Direct Lake on OneLake | Direct Lake on SQL Endpoints |
|---|---|---|
| Reads from | Delta Parquet files directly in OneLake (lakehouse Files/Tables) | SQL analytics endpoint (auto-generated from lakehouse or warehouse) |
| Data source | Lakehouse Delta tables | Lakehouse SQL endpoint or Warehouse tables/views |
| Performance | Optimal — direct Parquet read | Slightly more overhead — goes through SQL endpoint layer |
| Schema | Based on Delta table schema | Based on SQL endpoint schema (can include custom views) |
| Best for | Maximum performance on lakehouse data | When you need views or computed columns from the SQL layer |
When to choose each
| Choose OneLake when… | Choose SQL endpoint when… |
|---|---|
| Data is in a lakehouse and performance is top priority | You need SQL views or computed columns exposed to the model |
| The Delta table schema matches what the model needs | The warehouse has business logic in views that the model should use |
| You want the simplest, most direct path | You need cross-database queries reflected in the model |
Scenario: Raj optimises Direct Lake performance
Raj at Atlas Capital notices that his Direct Lake model occasionally falls back to DirectQuery during month-end reporting (when 200 analysts hit dashboards simultaneously).
His investigation reveals: the fact_trades table has 50 billion rows and the position_value column exceeds the F64 per-column memory limit.
Raj’s fixes:
- OPTIMIZE the Delta table to reduce Parquet file fragmentation
- Create an aggregate table (
agg_daily_trades) that reduces 50B rows to 5M rows - Point the semantic model at the aggregate table for high-level dashboards
- Keep the detail table for drill-through scenarios only
- Disable fallback on the production dashboard to guarantee performance
Direct Lake refresh behavior
Unlike Import mode, Direct Lake does not require traditional scheduled refreshes:
| Action | Import Mode | Direct Lake |
|---|---|---|
| Load data into model | Full or incremental refresh (minutes to hours) | Automatic framing from Delta log (seconds) |
| Detect source changes | Only at refresh time | Continuous — reads Delta transaction log |
| Manual refresh | Re-imports all data | Updates the frame (reads new Delta entries) |
| Cost | High (full data processing) | Low (only reads changes) |
You CAN still call refresh on a Direct Lake model — it forces a frame update, which is useful when you want the model to immediately reflect a large data load.
Anita at FreshCart has a Direct Lake semantic model that performs well most of the time but slows down significantly during peak hours. Investigation shows the model is falling back to DirectQuery. What is the most likely cause?
Raj at Atlas Capital needs to connect a Direct Lake semantic model to a warehouse view that joins three tables and includes computed columns. Should he use Direct Lake on OneLake or Direct Lake on SQL endpoints?
🎬 Video coming soon
Next up: DAX Performance Optimization — make your measures and queries faster with proven optimization techniques.