Fabric DirectLake on OneLake: Enterprise Performance Architecture for Sub-Second Dashboards Over 1B+ Rows

TL;DR

• DirectLake on OneLake is Microsoft Fabric's storage mode for Power BI semantic models that reads Delta tables directly from OneLake without an Import-mode refresh step and without DirectQuery's per-query SQL round-trip. The result is Import-mode-like query performance over data the size of a data warehouse.
• For enterprise tenants running billion-row datasets through Power BI, DirectLake changes the architecture conversation. The dataset-refresh time that used to be the dominant operational cost largely disappears; the new dominant cost is OneLake column-segment caching and capacity sizing for the working set.
• The three storage-mode framings — DirectLake, DirectLake on SQL endpoint, and DirectLake with Import fallback — solve different governance and performance trade-offs. This guide details when each applies.
• The V-Order optimization, applied to the Delta files in OneLake, materially affects DirectLake query performance. Tenants migrating existing Delta tables to OneLake should plan for a V-Order optimization pass.
• This guide is for enterprise data architects designing the DirectLake-on-OneLake architecture for Fortune 500 tenants with billion-row fact tables, mixed real-time and batch workloads, and regulated-industry governance scope.

Executive Summary

Power BI's three historical storage modes — Import, DirectQuery, and Composite — have each represented a trade-off between query performance and data freshness:

• Import delivers the fastest queries by loading data into the Vertipaq in-memory engine, but requires a refresh step that scales with data volume. A 5-billion-row fact table refresh can take hours and consume substantial capacity.
• DirectQuery delivers the freshest data by hitting the source on every query, but the query latency depends on the source's performance and the network round-trip.
• Composite combines the two for specific patterns but adds modeling complexity.

DirectLake, introduced with Fabric and matured significantly through 2025–2026, is the fourth storage mode. It reads Delta tables directly from OneLake on first query, caching the relevant column segments in memory. Subsequent queries against cached segments perform like Import. Queries against uncached segments incur a paging cost but no refresh-equivalent cost.

For enterprise data architects, this shifts the architecture conversation. The semantic model no longer "refreshes"; it caches on demand. The capacity-sizing question changes from "how much memory does my model need at peak" to "how much memory does my working-set need given my query pattern." This guide walks through that architecture for Fortune 500 enterprises with billion-row fact tables.

DirectLake Storage Modes

The May 2026 Fabric release matures three distinct DirectLake framings:

DirectLake (default)

The default DirectLake mode reads Delta tables directly from OneLake. The semantic-model engine maintains a column-segment cache; query execution loads segments on demand and serves from cache thereafter. There is no refresh step.

When the underlying Delta table is updated (a new write to the lakehouse, a streaming append, a periodic batch load), the semantic model "frames" — it picks up the new version of the table. The framing operation is fast (seconds, not minutes) because it does not load data; it only updates the model's pointer to the current Delta version.

This mode is the right choice for the majority of enterprise DirectLake implementations.

DirectLake on SQL endpoint

The second framing reads through the Fabric SQL endpoint rather than directly from the Delta files. This adds a slight query latency overhead but provides access to features that the direct Delta path does not yet support — primarily complex DAX patterns that the engine has not yet pushed down to OneLake directly.

This mode is the right choice for semantic models that depend on DAX patterns currently in the SQL-endpoint path only. The list of patterns changes with each Fabric release; verify against the current Fabric documentation.

DirectLake with Import fallback

The third framing combines DirectLake with an Import-mode fallback. When the engine encounters a query pattern that DirectLake cannot serve efficiently, it falls back to a small Import dataset that loads at framing time.

This mode is the right choice for transitional architectures where the team is migrating from Import to DirectLake but needs to preserve a subset of legacy patterns during the migration window. The fallback Import dataset should be small (typically aggregation tables or historical dimensions) and the fallback should be eliminated over time.

Mode selection decision matrix

Workload pattern	Recommended mode
Large fact table (>100M rows), simple star schema, standard DAX	DirectLake (default)
Same as above but DAX patterns require SQL-endpoint features	DirectLake on SQL endpoint
Mixed star + snowflake + complex measures	DirectLake on SQL endpoint
Hybrid: large fact + small aggregation tables for performance	DirectLake with Import fallback
Real-time streaming source feeding OneLake	DirectLake (default), framing on schedule
Sub-second query requirement, predictable working set	DirectLake (default) with capacity tuning

V-Order: The Optimization That Matters

V-Order is Microsoft's write-time optimization for Parquet files (which underlie Delta tables in OneLake). The optimization arranges column data within the Parquet file in a way that the Vertipaq engine can read more efficiently. The result is materially faster DirectLake query performance.

V-Order is enabled by default for new Delta tables written by Fabric experiences (Fabric Data Factory, Fabric Spark notebooks, Fabric Warehouse). However:

• Delta tables created by external tools (Databricks, Synapse, Azure Data Factory writing to ADLS) typically do not have V-Order applied unless explicitly configured.
• Shortcuts to external Delta tables inherit the source's V-Order status. A shortcut to a Databricks-written Delta table that does not have V-Order will not get V-Order from being shortcut-ed.
• Re-optimizing existing tables requires a OPTIMIZE operation with V-Order enabled.

For tenants migrating to OneLake from existing Databricks or Synapse environments, the V-Order optimization pass is a non-trivial workload. EPC Group's typical pattern:

1. Inventory the existing Delta tables and their write source.
2. For tables written by Fabric experiences: confirm V-Order is enabled (usually yes by default).
3. For tables written by external tools or shortcut-ed in from non-Fabric sources: schedule a V-Order optimization pass during a maintenance window.
4. For very large tables (>1B rows): consider a partition-by-partition V-Order optimization to spread the workload across multiple windows.

Capacity Sizing for DirectLake

The memory math

A Power BI semantic model in DirectLake mode consumes capacity memory based on the column segments it caches. The math:

• Each column segment is approximately 1MB of compressed columnar data.
• A column in a 1-billion-row fact table typically has 30–50 segments per partition.
• A fact table with 30 columns and a partition pattern that yields, say, 50 partitions per column, has ~75,000 segments total at maximum.
• Not all segments are loaded for a typical query — the engine loads only the columns and partitions involved in the active query and recent queries.

The capacity-sizing question becomes: how much of the model's column-segment surface is in the working set at any given time?

For most enterprise workloads, the answer is a small fraction of the maximum:

• Date-axis queries typically touch the current year and prior year (8% of a 25-year fact table).
• Dimensional queries typically touch dimension tables fully but fact tables sparsely.
• Trending analyses typically touch many columns but few partitions per column.

EPC Group's working-set estimate for a typical enterprise fact-table-backed semantic model is 15–30% of the column-segment surface during active business hours, peaking at 50% during heavy month-end or quarter-end analysis periods.

F-SKU sizing

Translating the working-set estimate to F-SKU sizing:

Model fact-row count	Working-set memory (typical)	Recommended F-SKU
50M rows	1–3 GB	F4 (8 GB capacity memory)
200M rows	4–10 GB	F8 (16 GB)
1B rows	15–30 GB	F32 (64 GB)
5B rows	50–100 GB	F64 (128 GB) or F128 (256 GB)
20B+ rows	100+ GB	F128+, often multi-capacity architecture

These are starting-point estimates. The actual right size depends on query pattern, column count, partition strategy, and concurrency. Capacity sizing should be validated against the Fabric Capacity Metrics app during pilot before broad rollout.

Multi-capacity architectures for very large datasets

For datasets that exceed the largest single F-SKU's capacity (currently F128 at 256 GB capacity memory), the architectural pattern is multi-capacity:

• By time partition. Historical data lives in one capacity; current-period data lives in another. Queries that span both use a Composite Power BI model.
• By business unit. Each business unit has its own semantic model on its own capacity. Cross-business-unit views use a Composite model.
• By workload separation. Heavy month-end batch analytics run on a dedicated capacity; daily operational queries run on a separate capacity.

The multi-capacity architecture adds operational complexity but is the correct path for datasets that exceed single-capacity bounds.

Performance Patterns for Sub-Second Dashboards

For executive dashboards where sub-second response time matters, the architectural patterns that consistently deliver on DirectLake:

Aggregation tables (Composite with Import fallback)

Even on DirectLake, the fastest path for high-traffic executive dashboards is an aggregation table — a pre-summarized version of the fact table at the dashboard's query grain. The aggregation table is much smaller and can be Imported for guaranteed sub-second response.

The DirectLake with Import fallback mode supports this pattern cleanly: the aggregation table is the Import portion; the detail-level fact table is the DirectLake portion. The user-experience layer (the visual) automatically uses the aggregation when the query is at the aggregation grain.

V-Order with appropriate partition strategy

A 1-billion-row fact table partitioned by date and V-Ordered queries the current month with negligible latency. The same table un-partitioned or un-V-Ordered queries the current month several times slower. Partitioning and V-Order are operational decisions that affect every dashboard built on the table.

Aggressive column hiding

Columns that are not used in any report should be hidden from the semantic model (isHidden = true in TMDL). Hidden columns are not loaded into the column-segment cache, reducing memory pressure and improving cache hit rates.

Calculated column reduction

DirectLake handles calculated columns differently from Import mode. Where possible, push calculated-column logic into the source Delta table (compute the column once during the data engineering step rather than at semantic-model load). This reduces DirectLake framing time and improves query performance.

Star schema discipline

Star schema (fact table joined directly to dimension tables) outperforms snowflake schema on DirectLake the same way it does on Import. The Vertipaq engine is optimized for star schema. Snowflake patterns force the engine into more complex join paths.

Implementation Framework

For Fortune 500 enterprises designing DirectLake-on-OneLake architecture, the EPC Group implementation pattern:

Weeks 1–4: Architecture and assessment.

• Current-state inventory: existing Power BI Import datasets, Direct Query datasets, source platforms (Synapse / Databricks / SQL Server / others).
• Target-state architecture: which datasets move to DirectLake, which stay on alternative modes.
• OneLake structure: lakehouses, warehouses, shortcuts to existing data.
• V-Order optimization plan for existing Delta tables.
• Capacity sizing estimate based on data volume + query pattern.

Weeks 5–8: Foundation.

• Provision Fabric F-SKU capacity (start with pilot-sized).
• OneLake lakehouse / warehouse implementation.
• Data engineering pipelines to populate OneLake from existing sources.
• Initial Delta table V-Order pass.
• Semantic-model migration patterns documented.

Weeks 9–16: Migration.

• Migrate semantic models from Import / DirectQuery to DirectLake, one model at a time.
• For each model: choose framing mode (DirectLake / SQL endpoint / Import fallback), validate query performance, tune.
• Aggregation table addition for executive dashboards.
• Star schema cleanup for snowflake patterns.

Weeks 17–20: Capacity tuning and optimization.

• Production traffic over the new architecture.
• Capacity-consumption monitoring and right-sizing.
• Query performance optimization across the top reports.
• Multi-capacity architecture rollout if dataset size required.

Weeks 21–24: Stabilization and handover.

• Documentation of the architecture and runbooks.
• Center-of-Excellence handover.
• Capacity-consumption chargeback model (if applicable).

The 24-week timeline is for a Fortune 500 tenant with substantial Power BI estate and billion-row scale. Smaller tenants run shorter.

Common Pitfalls

Across the DirectLake implementations EPC Group has guided, the recurring patterns:

1. Skipping the V-Order optimization on imported Delta tables. Tables migrated from Databricks or Synapse without a V-Order pass perform substantially worse than native Fabric-written tables. Optimize early.

2. Under-sizing the capacity. F-SKU sizing based on the old Premium P-SKU is often too small. Use the working-set estimate, then tune from production data.

3. Choosing DirectLake on SQL endpoint as the default. Many architects start with the SQL-endpoint mode "for safety." This is unnecessary for most workloads and adds a small but real query latency. Default to DirectLake direct; use SQL endpoint only where required.

4. Treating DirectLake as a refresh-elimination strategy without addressing the underlying data engineering pipeline. DirectLake removes the dataset-refresh step but the upstream Delta table still needs to be populated by a pipeline. The pipeline becomes the new bottleneck if not designed for the freshness requirement.

5. Forgetting about RLS and OLS performance. Row-Level Security and Object-Level Security continue to apply in DirectLake. Complex RLS expressions can become the dominant query cost. Test with representative RLS contexts during pilot.

6. Mixing capacity sizes inconsistently. Multi-capacity architectures require deliberate workload allocation. Workspaces drifting between capacities cause performance variation that is hard to diagnose later.

Frequently Asked Questions

What is DirectLake?

DirectLake is a Power BI storage mode introduced with Microsoft Fabric that reads Delta tables directly from OneLake without an Import-mode refresh step and without DirectQuery's per-query SQL round-trip. The semantic-model engine maintains a column-segment cache that loads on demand and serves subsequent queries from cache.

How is DirectLake different from Import mode?

Import mode loads all data into the Vertipaq engine at refresh time. DirectLake loads only the column segments needed by active queries, caching as it goes. Both serve queries from memory; the difference is when and how much memory is consumed.

How is DirectLake different from DirectQuery?

DirectQuery sends every query to the underlying source and waits for the SQL response. DirectLake reads directly from the Delta files in OneLake on first access and serves subsequent queries from in-memory cache. DirectLake performance is closer to Import; DirectQuery performance is bound by the source.

What is V-Order?

V-Order is Microsoft's write-time optimization for Parquet files (which underlie Delta tables). The optimization arranges column data in a layout that the Vertipaq engine reads efficiently. V-Order is enabled by default for Delta tables written by Fabric experiences but may not be present for tables written by external tools.

Do I need V-Order on my Delta tables?

For DirectLake performance, V-Order materially improves query latency. Delta tables that will back DirectLake semantic models should have V-Order applied. Tables consumed only by Spark or SQL workloads do not require V-Order.

What is "framing" in DirectLake?

Framing is the operation where the semantic model picks up the current version of a Delta table. The framing operation is fast (seconds) because it updates the model's pointer to the current Delta version, not the data itself.

Can I use DirectLake with shortcuts to external Delta tables?

Yes. OneLake shortcuts can point to Delta tables in external locations (ADLS Gen2, S3, GCS). DirectLake reads through the shortcut. Performance depends on the external location's read characteristics; V-Order may or may not be present.

How do I size an F-SKU capacity for a DirectLake semantic model?

Start with the working-set estimate: typically 15–30% of the model's full column-segment surface during normal operations, peaking at 50% during heavy periods. Translate to F-SKU memory based on the model's row count and column count. Validate against the Fabric Capacity Metrics app during pilot before broad rollout.

What is the largest dataset DirectLake can support?

The practical limit depends on the F-SKU. F128 (the largest standard F-SKU at the time of writing) supports 256 GB capacity memory, which typically maps to a working set of 100+ GB of column segments. Datasets above this size use multi-capacity architectures.

Can DirectLake serve real-time streaming data?

Yes. The streaming source writes to a Delta table in OneLake (typically via Fabric Real-Time Intelligence or a Spark structured streaming pipeline). DirectLake frames on schedule to pick up new versions. The latency from data arrival to query availability is the framing cadence — typically seconds to minutes.

How does DirectLake handle Row-Level Security?

RLS continues to apply in DirectLake. The RLS expression evaluates at query time against the user's context. Complex RLS expressions can become a dominant query cost; testing with representative RLS contexts during pilot is important.

What happens if my query needs data that isn't in the column-segment cache?

The DirectLake engine pages the relevant column segment in from OneLake. The first query incurs the paging cost; subsequent queries against the same segment serve from cache. The paging cost is typically sub-second to a few seconds depending on segment size and OneLake read latency.

Can I mix DirectLake and Import in the same semantic model?

Yes, through the DirectLake with Import fallback mode or a Composite model pattern. The common use case is large fact tables in DirectLake with small aggregation tables in Import for sub-second executive dashboards.

What is the difference between DirectLake and DirectLake on SQL endpoint?

DirectLake reads Delta files directly. DirectLake on SQL endpoint reads through the Fabric SQL endpoint, adding a small latency but providing access to features the direct path doesn't yet support. Default to direct DirectLake; use SQL endpoint where required.

How does EPC Group support DirectLake architecture?

EPC Group works with Fortune 500 enterprises designing and implementing DirectLake-on-OneLake architectures, typically as part of a broader Power BI Premium-to-Fabric F-SKU migration. The standard pattern is a 24-week engagement for a substantial existing Power BI estate. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct DirectLake architecture experience and a compliance-native delivery pattern.

Next Steps

If your enterprise is designing a DirectLake-on-OneLake architecture or planning a Power BI Premium-to-Fabric migration that includes DirectLake, the practical next steps:

1. Inventory existing Power BI Import datasets and identify migration candidates.
2. Assess existing Delta-table V-Order status across data sources.
3. Estimate working-set memory requirements for the priority models.
4. Provision a pilot F-SKU capacity and migrate 1–2 representative semantic models.
5. Engage a partner with deep DirectLake implementation experience to compress planning.

EPC Group has 29 years of enterprise Microsoft analytics experience and is Microsoft Solutions Partner with the core designations. We were historically the oldest continuous Microsoft Gold Partner in North America from 2016 until the program's retirement. Our consultants — including Microsoft Press bestselling author Errin O'Connor — bring direct DirectLake implementation experience across hundreds of regulated-industry engagements. To discuss your DirectLake architecture, contact EPC Group for a 30-minute discovery call.