Direct Lake is designed to give Power BI semantic models fast analytical access to Delta tables in Microsoft Fabric without copying those tables into a traditional Import model. But the phrase “Direct Lake fallback” now needs a precise 2026 explanation. Direct Lake on SQL analytics endpoints can fall back to DirectQuery when certain conditions are not met; Direct Lake on OneLake does not support DirectQuery fallback at all. For engineers working in Microsoft DP-600, understanding which Direct Lake architecture is in use is the first troubleshooting step.
The distinction matters because the operational symptoms differ. A Direct Lake on SQL model can continue answering a query by sending it through the SQL analytics endpoint, often with slower performance. A Direct Lake on OneLake model stays in Direct Lake mode; unsupported or invalid conditions are handled as errors rather than silently switching to DirectQuery. That newer OneLake-oriented architecture is part of the reason Fabric semantic-model design has evolved beyond the broader storage-mode comparison familiar from Microsoft PL-300.
Direct Lake on SQL and Direct Lake on OneLake are not the same architecture
Direct Lake on SQL uses the SQL analytics endpoint of a lakehouse or warehouse for schema and security discovery while loading Delta-table data directly from OneLake when Direct Lake conditions are satisfied. Because the SQL endpoint remains part of the model architecture, Power BI can use DirectQuery fallback for unsupported situations when fallback is allowed.
Direct Lake on OneLake connects more directly to OneLake storage and security. Microsoft’s current documentation recommends Direct Lake on OneLake for new semantic models where the feature set fits. The crucial troubleshooting fact is that Direct Lake on OneLake runs in DirectLakeOnly behavior and does not silently switch to DirectQuery.
Fallback is a compatibility path, not a performance feature
When Direct Lake on SQL falls back, the query is executed through the SQL analytics endpoint instead of loading the required columns directly from Delta storage into the semantic model’s in-memory structures. That preserves functionality for scenarios Direct Lake cannot serve natively, but it changes the query path and can increase latency.
A report that “still works” can therefore hide a material architecture change. Establish a performance baseline for important semantic models so fallback becomes visible as a regression rather than a vague user complaint. Record typical visual latency, capacity usage, and query mode during normal operation. When those signals change together, engineers can investigate the storage-mode path before spending time rewriting unrelated DAX. Analysts may notice slower visuals, higher SQL endpoint activity, or different bottlenecks without realizing that the semantic model stopped serving the query in Direct Lake mode. Monitoring should identify whether queries are using Direct Lake or fallback rather than treating response time alone as the diagnostic signal.
SQL views are a common reason Direct Lake on SQL falls back
Direct Lake expects materialized Delta tables. If a semantic model references an unmaterialized SQL view through the SQL analytics endpoint, Direct Lake cannot read the underlying result as a native Delta table for that query path. Direct Lake on SQL can handle this by falling back to DirectQuery.
The more durable fix is architectural: materialize the logic as a Delta table or supported materialized object when Direct Lake performance is required. A view can remain useful for SQL consumers, but a semantic model that depends on native Direct Lake behavior should not quietly inherit a query path that requires SQL execution. Treat the semantic layer and the SQL serving layer as distinct design surfaces. Leaving important business logic only in ordinary SQL views can turn a model that appears to be Direct Lake into a model that frequently behaves like DirectQuery.
SQL-based granular security can trigger fallback
Row-level security, object-level security, and dynamic data masking defined at the SQL analytics endpoint can force Direct Lake on SQL queries away from native Direct Lake processing. The semantic model must respect those controls, so the SQL endpoint becomes part of the query execution path.
Microsoft now offers multiple security layers, including semantic-model security and OneLake security for supported Direct Lake on OneLake scenarios. The design decision should therefore be deliberate: place data-access rules at the layer that matches the access pattern and understand the performance consequences. If report consumers also query the warehouse directly, SQL-layer policy may be appropriate. If the semantic model is the governed access boundary, model-level or OneLake security may provide a cleaner architecture. The security model should explain who is authorized and how the engine enforces that decision. Duplicating the same security logic at several layers can add management complexity without improving the user experience.
Capacity guardrails can push a Direct Lake on SQL model out of Direct Lake
Direct Lake has capacity-dependent guardrails for table size, row groups, Parquet-file counts, and memory behavior. If a table exceeds supported guardrails in a Direct Lake on SQL model, queries can fall back rather than using the expected Direct Lake path. One table breaching a guardrail can affect behavior for the model.
Guardrail problems are not solved by changing DAX alone. Track Parquet file counts, row-group shape, table growth, and memory pressure as data-engineering metrics, not only BI metrics. A semantic model can become slower over time without any DAX change if upstream ingestion creates many small files or if a table grows beyond the guardrail characteristics of the assigned Fabric capacity. Data layout, file count, row-group structure, capacity size, concurrent workload, and model design all matter. Delta optimization, file compaction, capacity tuning, and reducing unnecessary columns can be more effective than attempting to micro-optimize a report visual.
Framing determines which Delta state the semantic model can use
Direct Lake semantic models frame tables so the engine knows which Delta-table state is available for queries. After underlying table changes, a model may need to be refreshed or reframed before new structures are usable. A table that has not been framed after certain changes can become a fallback cause in Direct Lake on SQL.
Automatic updates simplify this lifecycle, but they are not magic. Microsoft notes that non-recoverable refresh failures can suspend automatic updates until a later successful refresh occurs. Operations teams should therefore monitor semantic-model refresh health instead of assuming Direct Lake automatically eliminates refresh-related administration. A deployment runbook should include a framing or refresh validation after schema changes, table additions, and major upstream transformations. New data appearing in Delta storage does not excuse the team from verifying that the semantic model understands the current table structure.
DirectLakeBehavior controls how Direct Lake on SQL responds
Direct Lake on SQL exposes a DirectLakeBehavior property that determines what happens when Direct Lake conditions are not met. Automatic behavior can silently use DirectQuery, while DirectLakeOnly behavior refuses to fall back. This creates a useful tradeoff between continuity and strict performance predictability.
In production reporting, automatic fallback can protect users from outright failures, but it can also hide an architecture problem for months. In performance-sensitive environments, teams may prefer stricter behavior during testing so unsupported design choices fail visibly before release. The correct setting depends on whether continuity or strict Direct Lake enforcement is more important for the workload. Teams can use strict behavior in development or performance testing to expose unsupported design choices early, then decide deliberately whether production should prefer hard failure or graceful compatibility. The important point is that the choice is intentional and monitored.
Use TABLETRAITS and performance tools to prove the execution path
Microsoft documents the DAX function TABLETRAITS() as a direct way to inspect fallback reasons for Direct Lake tables. The DirectLakeFallbackInfo output can show whether a table is using Direct Lake or why it is not. This is stronger evidence than guessing from report speed.
Performance Analyzer can reveal expensive visuals and DAX query duration, while SQL Server Profiler and other model-analysis tools can help identify query behavior. Combine these with capacity metrics and source-table health. A complete investigation asks whether the model is in Direct Lake, whether the needed columns fit memory and guardrails, and whether the report itself is generating expensive queries. Correlate the evidence by visual and time window: one visual can trigger fallback while another remains native, or one capacity-pressure period can create transient behavior that disappears later. Query-level evidence is more useful than labeling an entire report simply “fast” or “slow.”
Design for Direct Lake instead of accepting fallback as normal
Fallback should be treated as a signal that the model architecture deserves review, not as the expected steady state. DP-600 Fabric analytics connects Direct Lake with semantic-model design and lifecycle management; this troubleshooting problem narrows that engineering work to data shape, security layer, capacity, and the actual query path.
Teams building new models should also understand the direction of the platform. Microsoft’s current Direct Lake on OneLake architecture supports tables from multiple Fabric data sources whose OneLake storage resolves to supported Delta tables, while Direct Lake on SQL is tied to a single supported SQL-endpoint source. That difference can affect migration planning as much as performance. Moving to OneLake is an architecture decision, not a switch that every existing model can make without reviewing views, security, and source design. Direct Lake on OneLake removes DirectQuery fallback and supports a more direct OneLake security model. The wider comparison of Power BI and Microsoft Fabric helps explain the ecosystem, but production engineers should diagnose Direct Lake with exact architecture terms: OneLake versus SQL endpoint, native execution versus fallback, and supported design versus compatibility path.