Direct Lake is often described as the speed of Import with the freshness of a lake, but that shorthand hides the decisions that matter in production. A Direct Lake semantic model queries Delta-backed data in OneLake and loads required columns into memory as needed. It does not simply send every visual’s query to a SQL server, nor does it copy an entire source table during each report interaction. For the Microsoft DP-600 exam, the essential skill is understanding the query path, storage options, refresh behavior, capacity boundaries and security implications well enough to explain why a visual is fast, slow or failing.
Fabric supports two important Direct Lake architectures: Direct Lake on OneLake and Direct Lake on a SQL analytics endpoint. They share the basic goal of accessing Delta-backed data efficiently, but they have different dependency and fallback behavior. Treating them as identical can produce a design that works in a small demonstration and surprises users when SQL security or large tables enter the picture.
Follow the path from Delta table to visual
Data in eligible Delta tables is represented by Parquet data files and a transaction log. When a Direct Lake semantic model executes a DAX query, the engine determines which columns are needed by the selected measures, relationships and filters. It can then load relevant column data into memory, a process Microsoft calls transcoding. Repeated queries may benefit from the populated column cache, while the first query after a model or data change may require more I/O.
This column-oriented behavior changes how you optimize. A model containing dozens of rarely used text columns does not necessarily read all those columns for every visual, but columns that frequently participate in filters, relationships or measures can still be expensive. Large, high-cardinality identifiers, unnecessary calculated data and complex model relationships affect memory and execution. The improvement is not magic: Direct Lake reduces some data movement, yet a badly shaped model can remain slow.
Imagine a report showing daily net sales by region. It might require a date key, region key and net-amount column from a fact table, along with the relevant dimension keys. The semantic engine can work with those columns rather than scanning every descriptive field in the source table. If the report then opens a transaction detail page using a long free-text description, additional columns may have to be loaded. Such differences can explain a cold-query delay without implying a broken data connection.
Know the difference between framing and data ingestion
A Direct Lake refresh is not the same operation as importing every source row into a classic in-memory snapshot. Framing establishes the model’s view of the current Delta table state, including the metadata needed to work with the files that form that version. The underlying data is still loaded into memory on demand as queries require it. Therefore, refreshing the semantic model and ingesting new source records are separate steps in a data pipeline.
A common operational mistake is to assume that because a notebook wrote new rows to a Delta table, every semantic-model query must instantly reflect them in every configuration. Depending on the model’s automatic update behavior and architecture, framing and metadata synchronization may matter. Trace the sequence: source commit, Delta metadata, semantic-model framing, column cache and query. If an analyst reports stale figures, verify the actual data version at each stage before clearing caches or re-running the entire ingestion pipeline.
Framing also explains why a table newly added through model automation can require a refresh before it becomes queryable. The model needs to establish a valid relationship to the source table’s files and schema. Validate renamed tables, new columns and unexpected schema changes in a controlled environment, because a metadata mismatch can break measures or visuals even though the Delta table itself is healthy.
Choose Direct Lake on OneLake or on SQL knowingly
Direct Lake on OneLake works directly with supported OneLake Delta data and does not depend on the SQL analytics endpoint for its query path. This avoids certain endpoint security checks and fallback behaviors and is the preferred starting point for new solutions when its constraints fit the requirement. Direct Lake on SQL uses the SQL analytics endpoint for table discovery and relevant permission behavior, introducing a different set of possibilities when queries cannot remain in Direct Lake mode.
The most important behavioral difference is fallback. Direct Lake on SQL can use DirectQuery for a query when conditions prevent Direct Lake execution and the model allows fallback. This may preserve functionality but at higher latency and different load characteristics. Direct Lake on OneLake does not support that fallback path. Conditions that cannot be satisfied directly therefore require design changes or can result in an error rather than a silent switch to SQL-backed querying.
For example, a team exposes a SQL view over a lakehouse table and expects a Direct Lake semantic model to query the view exactly like a materialized Delta table. With Direct Lake on SQL, a view can trigger DirectQuery fallback rather than column loading from Delta. An architect who promised predictable in-memory behavior must either materialize the required shape into a supported table or accept and test the fallback. A design document should state the actual query mode instead of simply labeling the model “Direct Lake.”
Recognize guardrails before they become incidents
Direct Lake operates within capacity-specific constraints affecting such factors as file counts, row groups, row counts and model characteristics. Oversized or heavily fragmented Delta tables can create more metadata and work than the chosen capacity supports. Importantly, the consequences differ by Direct Lake architecture. A Direct Lake on SQL model may fall back where allowed, while a Direct Lake on OneLake model cannot quietly use the SQL path as an escape hatch.
The initial response should not always be “buy a larger capacity.” Examine the physical table: has a small-file problem developed because dozens of microbatches produced tiny files? Are partitions sensible for the actual read patterns? Can a gold-layer table pre-aggregate low-value detail? Are there unused columns or tables inflating memory demand? Optimize the Delta layout using supported maintenance processes, then retest the relevant semantic-model operation before deciding that capacity is the true bottleneck.
Capacity planning should use the concurrency and query shape of the business workload. A single developer opening one report is not a useful stress test for hundreds of sales users refreshing interactive pages at the start of the day. Cold-cache behavior, simultaneous visuals and other Fabric workloads can compete for resources. Baseline the cost of representative queries and monitor how it changes as data volumes and usage grow.
Do not conflate SQL security with model security
A semantic model can implement row-level and object-level controls for its consumers, while OneLake and SQL analytics endpoints have their own access mechanisms. The key is that permissions enforced at one surface do not automatically govern every alternative route to the same underlying files. SQL row-level security configured on an endpoint, for example, does not become universal file-level policy for a separate access path. Teams must map which engine performs the query and which security layer evaluates the request.
With Direct Lake on SQL, supported SQL endpoint security constructs can affect whether the engine can remain in Direct Lake mode. Some configurations lead to DirectQuery fallback. With Direct Lake on OneLake, security design follows OneLake permissions and the semantic model’s own rules; SQL endpoint permissions are not silently applied to direct OneLake reads. This is not a loophole to exploit but a boundary to understand. A test account should validate the actual report-consumption path as well as any separate lakehouse or SQL access granted to the same person.
Fixed-identity and single-sign-on arrangements also change which identity is used to reach underlying data. A report consumer may see only model-authorized rows without possessing direct access to raw files, while a privileged workspace member could have broader access through another tool. Review the whole access graph, not just a successful RLS test in the report. The wider Microsoft data and Fabric architecture depends on these distinctions.
Diagnose fallback with evidence, not speculation
If a report becomes unexpectedly slow after a schema or security change, compare the query path before and after. Microsoft documents ways to inspect Direct Lake behavior, including table-trait information that can reveal fallback reasons. A diagnostic DAX query such as EVALUATE TABLETRAITS() can be useful where supported. Also inspect performance traces, source-side SQL activity, refresh or framing results and the Delta table’s physical layout.
Common triggers include a nonmaterialized SQL view, unsupported endpoint security semantics, a table outside applicable guardrails or a source table not yet framed in the model. The remediation follows the cause. Materialize a required transformation into Delta if the view is responsible. Reconsider which layer should enforce RLS if endpoint rules force an undesirable query path. Optimize table layout or revisit capacity when a file or row-group constraint is the issue. Reframe after adding a new table where needed.
A troubleshooting note should record the failing visual, time, semantic-model mode, relevant table, capacity, measured latency and confirmed fallback or error reason. Without those facts, teams often “fix” the problem by changing refresh schedules or rewriting DAX that was not the source of the regression. Direct Lake makes the storage engine more flexible; it does not remove the need for a disciplined diagnosis.
Design for observability and controlled changes
Build the operational story before handing a Direct Lake model to report authors. Document which Delta tables it reads, whether it uses OneLake or SQL mode, how framing occurs, which identities are used and what should happen when data changes. Test schema revisions, lost permissions, altered shortcuts and table maintenance processes. Identify who owns each dependency, especially when the model uses data shared from another team or workspace.
For large solutions, a stable model schema and clean dimensional design may matter more than a clever storage setting. Use explicit measures, clear relationships and a limited number of necessary columns. Keep physical-engine optimization separate from the business definition of a metric. A technically successful Direct Lake query that calculates the wrong numerator is still a poor analytical product.
The DP-600 mental model is simple to state but demanding to apply: determine how the model discovers its tables, how the engine reads their data, how freshness is established, which capacity limits apply and where security is actually enforced. After that, choose a query mode that meets both performance and governance requirements. Direct Lake is valuable precisely because it gives architects another option; it is not a reason to abandon the fundamentals of modeling, monitoring and verification.