Direct Lake is a Power BI semantic model storage mode in Microsoft Fabric. It loads only the columns a query needs directly from Delta tables in OneLake into memory, then processes them with the same VertiPaq engine that powers Import mode. The result is Import-like query speed without maintaining a full imported copy of your data, and without the latency of DirectQuery.

For years, analytics teams have been forced to choose between two imperfect options: Import mode, which is fast but requires copying and refreshing entire datasets, or DirectQuery, which avoids duplication but adds query latency and leans heavily on the source system. Direct Lake was designed to close that gap. This guide explains how it actually works, when to use it, how it compares to Import and DirectQuery, and how to design for performance in production.

What Is Direct Lake in Microsoft Fabric?

Direct Lake is a table storage mode for Power BI semantic models, available only in Microsoft Fabric. It sits alongside the two long-established options , Import and DirectQuery , as a third choice that blends the strengths of both.

Here is what Direct Lake is not, because this is where most confusion begins:

• It is not a data lake. Direct Lake is a semantic model storage mode, not a storage location. Your data lives in OneLake.
• It is not the same as Delta Lake. Delta Lake is the open table format (backed by Parquet files) that stores your data. Direct Lake is the mechanism that reads those Delta tables into a semantic model.
• It is not DirectQuery. DirectQuery federates each query to the underlying source. Direct Lake loads columns into memory and serves them through VertiPaq.

In plain terms: you prepare your data as Delta tables in OneLake, and Direct Lake reads the columns it needs, on demand, into memory for fast interactive reporting.

How Does Direct Lake Work?

Direct Lake's behavior comes down to four core concepts: column loading (transcoding), framing, automatic updates, and DirectQuery fallback. Understanding these four is the difference between a model that flies and one that mysteriously slows down.

Delta Tables in OneLake

Every Direct Lake model reads from Delta tables stored in OneLake. The underlying storage for a Delta table is one or more Parquet files, which organize data by column rather than by row. This columnar layout is exactly why Direct Lake can load a small number of columns quickly instead of scanning entire rows.

Column Loading (Transcoding)

Direct Lake loads data from OneLake only when a query requests a column for the first time. This on-demand process is called transcoding.

When the model receives a DAX (or MDX) query, it first works out which columns are actually needed , the columns used directly, plus those required by relationships and measures. Typically that is a small fraction of the columns defined in the model. It then checks which of those are already in memory and loads only the missing ones from OneLake. Once loaded, a column stays resident in memory, so future queries that use only resident columns don't trigger any new loading.

This is why the first query against a "cold" model can feel slower , you're paying for the initial warm-up , while subsequent queries against warm columns perform like Import mode.

Framing and Data Freshness

A refresh in Direct Lake is fundamentally different from an Import refresh. Import mode copies the entire dataset into a cached in-memory copy. A Direct Lake refresh, by contrast, copies only metadata , a low-cost operation known as framing that can complete in seconds.

Framing analyzes the metadata of the latest version of the Delta tables and updates the model's references to point to the newest Parquet files in OneLake. It does not re-copy the data. This is what gives Direct Lake near-real-time freshness without the cost of a full refresh cycle.

Column Eviction and Memory Management

A resident column does not stay in memory forever. It can be evicted when:

• The model or table is reframed after a Delta table update at the source.
• No query has used the column for a period of time.
• The capacity comes under memory pressure and needs to reclaim space.

This is why capacity sizing and query patterns matter so much , an under-provisioned capacity evicts columns more aggressively, forcing repeated cold loads.

DirectQuery Fallback

Under certain conditions, a Direct Lake on SQL model can seamlessly switch a query to DirectQuery , retrieving data directly from the SQL analytics endpoint of the lakehouse or warehouse. This is called fallback, and while it keeps reports working, it typically results in slower performance. (Direct Lake on OneLake does not support fallback , more on that distinction next.)

Direct Lake on OneLake vs Direct Lake on SQL

This is the single most important update to understand, because Direct Lake now comes in two flavors. Both are still Direct Lake storage mode , VertiPaq loads column data on demand from Delta tables in OneLake , but they differ in how they discover tables, check permissions, and handle fallback.

Choose Direct Lake on OneLake when you need to combine tables from multiple lakehouses or workspaces into one model, you want OneLake security, and you want to guarantee you stay on the fast in-memory path.

Choose Direct Lake on SQL when you depend on SQL analytics endpoint security, you reference SQL views, or you want DirectQuery fallback as a safety net for unsupported scenarios.

Direct Lake vs Import vs DirectQuery

Direct Lake and Import queries are both processed by VertiPaq, so they deliver comparable interactive performance , but Direct Lake avoids the overhead of copying and refreshing the entire data volume. And because only the columns needed to answer a query are loaded, the analyzed data volume can exceed the capacity's maximum memory limit, which is impossible with Import mode.

When Should You Use Direct Lake?

Direct Lake is ideal when:

• You're building semantic models on large Fabric lakehouses, warehouses, or other Fabric sources with Delta tables.
• Replicating the entire data volume into an Import table is impractical or impossible because of its size.
• You want the gold analytics layer of a medallion architecture to serve reports directly, without a separate import step.
• You need high-volume Power BI reporting with fresh data but can't afford long, resource-heavy refresh cycles.
• You want to maximize ROI by analyzing datasets larger than your capacity's memory ceiling.

Direct Lake is less suitable when your data isn't in Delta table format, when you need extremely complex modeling features not yet supported, or when a small dataset would run perfectly well , and more simply , in Import mode.

A Practical Direct Lake Architecture

A typical enterprise flow looks like this:

Source systems → Fabric pipelines / Dataflows / Spark → OneLake Delta tables (gold layer) → Direct Lake semantic model → Power BI reports

The critical shift for architects: performance now lives upstream. With Import mode, refresh settings dominated performance tuning. With Direct Lake, the biggest levers are Delta table design, capacity sizing, and storage optimization in OneLake. Get the data layer right and the reporting layer takes care of itself.

Direct Lake Performance Best Practices

• Optimize your Delta tables. Run `OPTIMIZE` to consolidate small Parquet files into larger ones , too many small files slow queries and increase cold-start time. Keep V-Order optimization enabled for better compression and faster column scans.
• Partition thoughtfully. Partitioning by year or month lets the engine read only the slices it needs, but over-partitioning creates too many small files and hurts performance.
• Design a clean star schema. Direct Lake follows the same modeling principles as Import , good relationships and well-structured fact and dimension tables matter.
• Watch high-cardinality columns. Column load time depends partly on cardinality; unnecessary high-cardinality columns increase transcoding cost.
• Load only what you need. Keep models lean so transcoding pulls the smallest possible set of columns.
• Right-size your capacity. An undersized F-SKU evicts columns aggressively and forces repeated cold loads. Monitor with the Fabric Capacity Metrics app.
• Prewarm critical models. Because the first query is slower, consider warming key columns before peak usage so users get Import-like speed from the start.
• Test for fallback. Even a model that shows "Direct Lake" as its storage mode can run individual DAX queries in DirectQuery. Verify with DAX Studio or Performance Analyzer during development.

Direct Lake Security and Governance

Security is where the two flavors diverge most sharply.

• Row-level security (RLS) at the SQL layer triggers DirectQuery fallback. When RLS or OLS is defined on the SQL analytics endpoint, Direct Lake can't push those filters into VertiPaq, so it falls back to DirectQuery and loses the in-memory performance advantage.
• Dynamic RLS in the semantic model is the recommended approach. DAX roles using `USERPRINCIPALNAME()` or `USERNAME()` run natively within VertiPaq and do not trigger fallback, as long as filtering happens on tables loaded into the Direct Lake frame.
• Direct Lake on OneLake uses OneLake security, which lets you enforce access at the OneLake layer and combine tables across multiple lakehouses and workspaces.
• Keep warehouse RLS/OLS focused on small lookup tables, and consider a separate model for highly secured data so your main fact tables stay on the fast path.

Access is verified against the effective identity, and supports workspace roles, item permissions, and OneLake security roles depending on your configuration.

Limitations and Design Considerations

Rather than generic disadvantages, here are the real architectural factors to plan for:

• Capacity and memory , analyzed data can exceed memory, but sizing still governs eviction and cold-load frequency.
• Delta table guardrails , tables exceeding the row group or Parquet file limits for your F-SKU can trigger fallback (on SQL) or errors (on OneLake).
• Column cardinality , affects transcoding speed.
• SQL views , not readable as files; they force DirectQuery fallback on the SQL flavor.
• Unsupported constructs , certain calculated columns/tables on Direct Lake tables can cause fallback.
• Fallback is dynamic , a query that ran in Direct Lake during testing isn't guaranteed to stay there in production; monitor fallback rates after deployment.

How to Implement a Direct Lake Semantic Model

1. Prepare your data in OneLake as optimized Delta tables (ideally your gold layer).
2. Run OPTIMIZE and confirm V-Order to keep Parquet files healthy.
3. Choose your flavor , Direct Lake on OneLake for multi-source and fallback-free behavior, or Direct Lake on SQL for SQL-based security and views.
4. Create the semantic model , you can build and live-edit Direct Lake models directly in Power BI Desktop while the data stays in OneLake, with support for version history, Git integration, and deployment pipelines.
5. Design a star schema and define measures and relationships.
6. Apply RLS in the model (not the SQL layer) to avoid fallback.
7. Test with DAX Studio / Performance Analyzer to confirm queries stay in Direct Lake.
8. Prewarm and monitor with the Fabric Capacity Metrics app.

How WaferWire Helps Organizations Implement Microsoft Fabric Direct Lake

Direct Lake shifts the hard work upstream , into architecture, capacity planning, and storage design. That's exactly where a specialist partner earns its keep. WaferWire helps enterprises:

• Assess Fabric readiness and design the right lakehouse/warehouse architecture.
• Plan capacity and SKU sizing to balance cost against performance and minimize eviction.
• Modernize and optimize the OneLake gold layer with well-structured, V-Ordered Delta tables.
• Build high-performance Direct Lake semantic models with clean star schemas and native RLS.
• Tune query performance and eliminate unnecessary DirectQuery fallback.
• Implement security and governance across OneLake and SQL endpoints.
• Move from proof-of-concept to production with monitoring and deployment pipelines.

If you're weighing Import vs Direct Lake , or fighting unexpected fallback , our team can help you design an architecture that stays on the fast path.