Direct Lake Mode in Microsoft Fabric
Query OneLake data with import-like performance using Direct Lake mode. Eliminate data duplication and reduce refresh times in Microsoft Fabric.
Direct Lake is the third storage mode in Power BI—joining Import and DirectQuery—and it fundamentally changes how semantic models access data. Import mode copies data into the model for fast queries but requires scheduled refreshes. DirectQuery queries the source live for fresh data but with slower performance. Direct Lake eliminates this trade-off: it reads Delta Parquet files directly from OneLake with near-import query speeds and near-real-time data freshness, without copying data into the model. For organizations building on Microsoft Fabric, Direct Lake is the recommended default storage mode. Our Microsoft Fabric consulting team helps organizations migrate existing import models to Direct Lake for improved performance and data freshness.
How Direct Lake Works
The Three-Phase Process
Direct Lake operates through a process called "framing" that makes OneLake data available to the VertiPaq query engine:
Phase 1: Framing (Metadata Refresh) When a Direct Lake model refreshes, it does not copy data. Instead, it scans the Delta table's transaction log to identify which Parquet files contain the current version of the data. It builds a lightweight metadata frame—a map of file paths, column offsets, and row group statistics. This frame typically completes in seconds, even for tables with billions of rows.
Phase 2: On-Demand Column Loading When a query arrives, VertiPaq reads only the columns and row groups needed to answer the query, loading them from Parquet files into memory. Once loaded, column data is cached in memory for subsequent queries. This is fundamentally different from Import mode, which loads all columns at refresh time.
Phase 3: Automatic Cache Management As queries arrive, frequently accessed columns stay in memory while rarely accessed columns may be evicted under memory pressure. The engine manages this cache automatically—no configuration needed. If a required column has been evicted, it is re-read from OneLake transparently.
Fallback to DirectQuery
When Direct Lake cannot satisfy a query from its cached Parquet data, it falls back to DirectQuery mode—sending a SQL query to the Lakehouse SQL analytics endpoint. Fallback happens when:
| Fallback Trigger | Why It Happens | Impact | |---|---|---| | Unsupported DAX function | Some DAX functions cannot operate on Parquet-cached data | Query runs slower via SQL endpoint | | Column not in cache + memory pressure | More columns requested than can fit in memory | First query slow, subsequent faster after caching | | Delta table too many files | Table has thousands of small files without optimization | Framing overhead increases, may trigger fallback | | Row-level security with complex filters | Some RLS patterns force DirectQuery evaluation | Security-filtered queries run slower |
Fallback is seamless to users—they get correct results—but performance degrades significantly. Monitoring and minimizing fallbacks is the primary optimization task for Direct Lake models.
Direct Lake vs Import vs DirectQuery
| Capability | Import | DirectQuery | Direct Lake | |---|---|---|---| | Query performance | Fastest (all data in memory) | Slowest (every query hits source) | Near-import (columns loaded on demand) | | Data freshness | Stale until refresh | Real-time | Near-real-time (after framing) | | Storage duplication | Full copy in model | None | None (reads from OneLake) | | Refresh time | Minutes to hours (data copy) | None needed | Seconds (metadata frame only) | | Dataset size limit | 400GB (Premium) | Source-limited | Capacity memory-limited | | DAX support | Full | Limited (some functions restricted) | Most (some trigger fallback) | | Data source | Any supported connector | SQL/AS sources | OneLake Delta tables only | | Licensing | Pro, PPU, Premium, Fabric | Pro, PPU, Premium, Fabric | Fabric capacity only |
Setting Up Direct Lake
Step 1: Prepare Delta Tables in Lakehouse
Direct Lake requires data stored as Delta tables in a Fabric Lakehouse (or Warehouse). The quality of your Delta table design directly impacts Direct Lake performance:
- Optimize table files: Run OPTIMIZE on Delta tables to compact small files into larger ones. Direct Lake performs best when tables have fewer, larger Parquet files (100MB-1GB each).
- Enable V-Order: V-Order is a Fabric-specific write optimization that sorts data within Parquet files for optimal VertiPaq compression. Fabric Spark enables V-Order by default; verify it is not disabled.
- Minimize column count: Remove columns that no report will ever use. Every column increases the metadata frame size and potential memory consumption.
- Use appropriate data types: Integer keys, fixed-decimal for financial amounts, and narrow string columns compress better than wide text fields.
Step 2: Create the Semantic Model
From the Lakehouse, click "New semantic model" and select the tables to include. The model is automatically created in Direct Lake mode:
- Define relationships: Set up star schema relationships between fact and dimension tables using integer surrogate keys
- Create measures: Write DAX measures as you would for any Power BI model. Most DAX functions work natively with Direct Lake.
- Set up hierarchies: Define drill-down hierarchies in dimension tables
- Configure RLS: Implement row-level security roles (simple filter expressions work natively; complex DAX filters may trigger fallback)
Step 3: Frame and Validate
After creating the model, the initial frame runs automatically. Verify performance by:
- Opening a connected Power BI report or using DAX Studio
- Running representative queries and checking response times
- Monitoring for fallback events in the Fabric Monitoring Hub
- Comparing query plans between Direct Lake and expected Import behavior
Monitoring and Optimization
Detecting Fallbacks
Fallbacks are the primary enemy of Direct Lake performance. Monitor using:
- Fabric Monitoring Hub: Shows query execution details including whether Direct Lake or DirectQuery handled each query
- DAX Studio: Connect via XMLA endpoint and use Server Timings to see whether VertiPaq (Direct Lake) or DirectQuery (fallback) processed each query
- Capacity Metrics App: Track overall Direct Lake vs DirectQuery query ratios across all models on your capacity
Optimization Strategies
Reduce file fragmentation: Schedule regular OPTIMIZE commands on Delta tables. Tables with hundreds of tiny files (from streaming inserts or small batch loads) cause slow framing and increased fallback probability.
Apply V-Order sorting: If tables were created without V-Order, rewrite them with V-Order enabled. The compression improvement can reduce memory requirements by 30-50%.
Minimize calculated columns: Direct Lake handles measures efficiently but calculated columns add processing overhead. Move calculations to the ETL layer (Spark notebooks or dataflows) whenever possible.
Partition large tables: Partition fact tables by date for tables exceeding 100 million rows. This enables Direct Lake to load only relevant partitions when queries filter by date range.
Control model memory: Direct Lake models have memory guardrails based on capacity SKU. If your model exceeds the guardrail, all queries fall back to DirectQuery. Monitor model memory consumption and upgrade capacity if needed.
Memory Guardrails by SKU
| Fabric SKU | Max Memory per Model | Max Model Size on Disk | |---|---|---| | F2 | 3 GB | 10 GB | | F4 | 3 GB | 10 GB | | F8 | 3 GB | 10 GB | | F16 | 5 GB | 20 GB | | F32 | 10 GB | 40 GB | | F64 | 16 GB | unlimited | | F128+ | 32 GB+ | unlimited |
When a model exceeds the memory guardrail, the entire model falls back to DirectQuery until the framing process can produce a model that fits within limits. This is the most common cause of poor Direct Lake performance in production.
Common Pitfalls
- Not running OPTIMIZE: Small files from streaming or frequent small loads fragment Delta tables, causing slow framing and frequent fallbacks
- Too many columns: Including every source column in the model wastes memory. Audit and remove unused columns.
- Ignoring fallback monitoring: Without monitoring, organizations run in DirectQuery mode for weeks without realizing Direct Lake framing failed
- Complex RLS patterns: Multi-table RLS with AND/OR logic may force DirectQuery fallback. Simplify RLS expressions to single-table filters where possible.
Related Resources
Frequently Asked Questions
When should I use Direct Lake vs Import?
Use Direct Lake when your data is in OneLake Lakehouses and you want fresh data without copying. Use Import when you need complex transformations, data from multiple sources, or when Direct Lake falls back too frequently.
What happens when Direct Lake falls back to DirectQuery?
If a query cannot be satisfied from the Direct Lake cache (due to unsupported operations or missing columns), it falls back to DirectQuery mode, which may be slower. Monitor fallbacks and optimize to minimize them.