DirectLake’s Quiet Exit: When It Falls Back to DirectQuery

The Executive Insight

Direct Lake is the feature that makes Fabric’s story compelling: import-mode query speed without an import refresh, reading straight from Delta tables in OneLake. When it works, it’s the best of both worlds.

The problem is the word “when.” Direct Lake on a SQL analytics endpoint can quietly fall back to DirectQuery mid-query, and when it does, performance drops from in-memory-fast to source-query-slow. Nothing errors. Nothing alerts. The report just gets sluggish, and because the fallback is dynamic and query-by-query, it’s genuinely hard to reproduce and debug after the fact.

This issue is about that silent exit: what triggers it, why a model that tested clean in development can fall back in production, and the one setting that turns the silence into a signal.

Two Direct Lakes, Two Fallback Stories

First, a distinction that matters before anything else, because the fallback behavior depends entirely on it.

There are now two Direct Lake variants. Direct Lake on SQL endpoints reads through the lakehouse or warehouse SQL analytics endpoint, and it’s the one that can fall back to DirectQuery. Direct Lake on OneLake is newer, isn’t coupled to the SQL endpoint, and does not support DirectQuery fallback at all. When Direct Lake on OneLake can’t satisfy a query within guardrails, it doesn’t quietly downgrade; the visual returns an error instead.

So the “silent slowdown” problem in this issue is specifically a Direct Lake on SQL endpoints behavior. If you’re on Direct Lake on OneLake, your failure mode is a visible error, not a quiet performance cliff, which is a different operational trade-off entirely. Everything below is about the SQL-endpoint variant.

What Actually Triggers Fallback

Fallback isn’t random. On a SQL-endpoint model, a query drops to DirectQuery when it hits something Direct Lake can’t serve from its in-memory column store. The main triggers:

A query touches a SQL view rather than a materialized Delta table. Views can’t be transcoded into the column store, so any query that references one falls back.

Security defined at the SQL analytics endpoint. If a referenced table has row-level security, object-level security, or dynamic data masking defined at the SQL endpoint, Direct Lake falls back to DirectQuery to enforce it correctly. There’s a sharp edge here: if the SQL endpoint is switched to single sign-on, OneLake security roles get pushed down as SQL access rules, and the model then falls back to DirectQuery 100% of the time.

A table exceeds the capacity guardrails. Too many Parquet files, too many row groups, or too many rows in a single table (the exact limits scale with your SKU) push that table out of Direct Lake. And a single table exceeding a guardrail prevents Direct Lake mode for the whole model, not just that table.

You queried before framing. If the Delta tables changed but the semantic model hasn’t been refreshed (framed) to point at the new Parquet files, queries won’t be served cleanly from the current column store.

Why It Passes in Dev and Fails in Production

This is the part that makes fallback genuinely painful, and worth a leader’s attention.

The storage mode label lies to you. A model built in web modeling will show its tables as “Direct Lake” even when individual DAX queries are actually running in DirectQuery. The partition storage mode and the per-query execution mode are not the same thing, so “it says Direct Lake” is not evidence that queries are running in Direct Lake.

And the behavior is dynamic. A query you tested in Direct Lake during development has no guarantee of staying in Direct Lake in production, because the triggers above depend on live conditions: data volume crossing a guardrail as tables grow, a view getting introduced upstream, security being added at the endpoint, small files accumulating from frequent writes. A model that was clean at launch drifts into fallback as the estate around it changes. That’s why users report “the report got slow” months in, with nothing obvious to point to.

The Guardrail: Turn the Silence Into a Signal

Here’s the lever. Direct Lake on SQL endpoints has a DirectLakeBehavior property with three settings: Automatic (the default, which allows fallback), DirectLakeOnly (which disables fallback), and DirectQueryOnly.

The pattern the field has converged on is to use these two settings for two different jobs:

In development, set the model to DirectLakeOnly. Now any query that would have silently fallen back instead fails loudly. That turns an invisible production performance problem into a visible development-time error you can actually find and fix, whether that means materializing a view, moving security to the semantic model layer, or optimizing the Delta tables.

In production, run on Automatic. Fallback is a safety net there: you’d rather a report render slowly than fail outright for an end user. The point isn’t to ban fallback in production; it’s to make sure you know where it happens before you ship.

Between those two, you close the reproducibility gap. You stop discovering fallback from a user complaint and start discovering it at your desk.

Hope for Lean Teams

You don’t need deep tooling to stay ahead of this. A few habits cover most of it.

Design to avoid the triggers where you can: prefer materialized Delta tables over SQL views in the model, and where per-user security is needed, enforcing RLS at the semantic model layer keeps queries in fast in-memory mode rather than forcing SQL-endpoint fallback. Keep your Delta tables optimized so file and row-group counts stay inside the guardrails, and refresh (frame) after the data changes. And flip on DirectLakeOnly in development for a build to see, immediately, which queries would have fallen back. That single test surfaces most fallback problems before a user ever meets them.

That’s Direct Lake reliability for a lean team: know the triggers, test with fallback off, and ship with it on.

Where I Fit In

Direct Lake is where Fabric either delivers its headline promise or quietly fails to, and the difference usually comes down to whether someone designed the model and the security around the fallback triggers rather than into them. The debugging (why is this one report slow, why only sometimes, why now) is exactly the kind of dynamic problem that eats a lean team’s week.

If your Direct Lake reports are fast in some places and mysteriously slow in others, and you want to find where they’re falling back before your users do, let’s talk.

Direct Lake’s best feature and its worst debugging problem are the same thing: it decides, per query, whether to be fast. Design around the fallback triggers and test with fallback disabled, and it stays fast where it counts.

Next week, we head to the edge: real-time intelligence in Fabric, and how Eventstreams and Eventhouse handle sensor and telemetry data for verticals like oil and gas and manufacturing.

Isaac Truong | Founder, Allston Yale

Enterprise-grade analytics for $50M–$100M SMBs

Power BI | Fabric | Azure | Data Strategy

Book a 20-min Fabric diagnostic →

Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates)

LinkedIn: Connect with me for daily Fabric tips

Friday Fabric Facts #23: Originally Posted on LinkedIn, July 3, 2026