Direct Lake and DirectQuery both reduce reliance on the traditional full-data import pattern, but they answer queries in materially different ways. In Microsoft Fabric, Direct Lake semantic models work over Delta tables in OneLake and can load column data into an in-memory engine as queries require it. DirectQuery instead issues queries to a supporting data source and returns results through that source’s execution path. The practical choice is not “which feature is newer?” It is where work executes, which security system evaluates access, how quickly new data becomes visible, and what happens when the model reaches a performance or compatibility boundary.
Start with the report’s latency promise
A retail operations team wants a dashboard showing sales from the previous hour, while finance needs consistent daily figures that survive reconciliation. Both groups might use the same underlying Delta tables, but they have different definitions of freshness. With Direct Lake, query results depend partly on model framing and on-demand loading of columns. With DirectQuery, results are read from the connected source at query time, subject to source latency and caching choices. Neither mode guarantees that a record emitted by a source system seconds ago has reached the analytical table. The ingestion and transformation pipeline is the first component in the freshness contract.
Ask how soon the analytical table is updated, when the semantic model sees changes, and whether the report expects a consistent snapshot across all related tables. A dataset may contain one recently updated fact table and one dimension still being refreshed; a dashboard can become semantically inconsistent even while every visual loads promptly. Model designers should define acceptable staleness in business terms and test it through a known source change rather than only inspecting mode labels. Small differences in load behavior matter greatly when users interpret a metric as an operational trigger.
Understand how Direct Lake reads columns
Direct Lake can load requested columns from the Parquet files behind Delta tables into the model’s in-memory storage engine. A report asking for two measures may not need every column in a very wide source table. This can provide analytical performance without making a separate scheduled copy through the traditional import model. However, performance still depends on data shape, capacity, relationships, and the amount of column data required by queries. A poor model with high-cardinality identifiers or expensive DAX measures does not become efficient merely because its tables use Direct Lake.
Framing determines which Delta table version or data state the model recognizes for querying. Automatic updates and manual refresh behavior require operational understanding, especially if an underlying table’s schema changes. Model designers should test how a new partition, column, or corrected record becomes visible and how the model behaves if it encounters a temporary access or schema problem. The relevant measure is not only query speed but whether the report remains consistent, interpretable, and recoverable when the pipeline evolves.
DirectQuery keeps execution at the source
DirectQuery sends queries through a supported connection and relies on the source system to process them. That may be useful when data must stay in its current engine or when specific source-side controls are central to the design. It also means concurrency, network latency, data source optimization, and query translation influence report responsiveness. A visual that generates several queries can place surprising load on an operational system. Caching and model simplification can help, but the architecture should not assume that the source will respond with warehouse-style performance under interactive report traffic.
The tradeoff becomes visible in high-cardinality filtering and expensive joins. A DirectQuery model whose source lacks selective indexes, efficient partitioning, or appropriate capacity can feel slow even if a single SQL test appears acceptable. Conversely, a well-managed analytical warehouse may answer particular live queries efficiently. Measure the actual generated query patterns and user concurrency. The decision is about predictable service-level behavior, not simply the fact that a SQL endpoint exists.
Direct Lake has two important variants
Direct Lake on OneLake and Direct Lake on SQL analytics endpoints must not be treated as identical. Microsoft’s current documentation distinguishes their source flexibility and fallback behavior. Direct Lake on OneLake does not support DirectQuery fallback; when a query cannot be processed within supported Direct Lake behavior, an error may result. Direct Lake on SQL analytics endpoints can fall back to DirectQuery for certain conditions, such as unsupported SQL views or source-side security configurations. Those fallbacks preserve result availability in some cases but can introduce slower query execution and a changed performance profile.
A design review should therefore name the specific variant instead of saying only “Direct Lake.” If a report unexpectedly becomes slow after a policy change, inspect whether fallback occurred and why. The remedy might involve moving a security definition into the appropriate model layer, materializing a SQL view as a Delta table, changing table shape, or sizing capacity for the workload. Do not automatically disable fallback in production without understanding whether queries would then fail outright. Use strict behavior during tests when it helps expose hidden dependencies.
Security placement changes both performance and risk
A business unit may require row-level security so managers see only their region, and object-level security so sensitive fields are not exposed. Those controls can be defined at different layers depending on the Fabric design. With Direct Lake on SQL analytics endpoints, certain SQL-level security controls can cause queries to fall back to DirectQuery. Direct Lake on OneLake has its own access-control path and integrates with OneLake security roles. The choice affects who must hold permissions, how fixed and delegated identities behave, and which engine enforces a particular rule.
A dangerous mistake is validating security only as a workspace administrator. Users with different roles may take a different path through the model. Build a matrix of roles and representative rows, test expected access and expected denials, and repeat the test after moving between environments. Performance tests should use those same identities; a report that is fast under one privileged account may be much slower under consumer-level security settings. Security and performance are coupled implementation concerns, not separate postlaunch audits.
Guardrails and Delta table health matter
Direct Lake performance is influenced by the physical Delta table layout, the number of files and row groups, capacity pressure, and other platform constraints. An append-heavy process generating many small files can degrade analytical behavior even if the SQL queries are logically simple. Compaction and table maintenance may therefore be part of BI operations. A single table that exceeds relevant guardrails can affect how a model processes queries. Engineers should understand the current guardrails for their Fabric capacity rather than reproduce static thresholds from an old article.
Before increasing capacity, inspect table health and model design. Remove unnecessary columns from high-demand queries where possible, improve relationships, and simplify DAX that forces large intermediate computations. Monitor whether fallback or error rates increase when the dataset grows. A performance change after compaction, an access-policy deployment, or schema evolution is evidence about the architecture; capture it along with the exact configuration so the team can identify cause and effect.
Choose by a testable decision record
Suppose a service center wants near-real-time analytical summaries from Fabric Delta tables and its report only needs approved semantic measures. Direct Lake on OneLake may be a sensible candidate if its security and modeling requirements fit the available behavior. Suppose instead a report relies on a SQL view with complex source-side security; DirectQuery or Direct Lake on SQL with an understood fallback path may deserve evaluation. Neither answer is universally superior. Test representative filters, concurrent report usage, role-specific security, update lag, and error recovery.
For a DP-600 candidate, understanding these tradeoffs is part of designing dependable Fabric analytics rather than memorizing a storage-mode label. Document which behavior is nonnegotiable: avoiding duplicate copies, preserving source-side authorization, meeting an interactive latency target, or showing corrections immediately. Record which tests established those properties and what monitoring will detect regression. The strongest engineering choice is a mode that supports the business semantics reliably, with a known explanation for its exceptional cases. Direct Lake and DirectQuery become useful when the team can describe their execution paths and failure boundaries instead of arguing from product labels.
A test matrix for choosing storage modes
Build a small test model over two Delta tables: transactions and customer permissions. Load data with known late corrections, and define a restricted user who may see only a subset of records. Run the same filters under candidate modes where platform support allows, record the actual execution path, and use an observability trace rather than trusting a property screen. Measure first-query latency, subsequent latency, concurrency, freshness after a controlled data update, and behavior when a source view or security rule changes. Now deliberately stress capacity or table size enough to expose applicable guardrails in a safe environment. If the SQL-endpoint variant falls back to DirectQuery, record the reason and effect; if the OneLake variant cannot fall back, record the error boundary. The experiment demonstrates that the right choice depends on security and operational behavior alongside speed. It gives stakeholders a defensible decision record and a monitoring plan grounded in realistic workloads rather than a feature comparison table.