Direct Lake is the headline feature of Microsoft Fabric's semantic model story: query Delta tables straight off OneLake with import-mode speed and no scheduled refresh. It's genuinely fast — until, quietly, it isn't. The report still loads, the numbers still look right, but every visual takes three seconds instead of three hundred milliseconds. Nine times out of ten, that's fallback.
What fallback actually is
When a Direct Lake semantic model can't satisfy a query directly against the OneLake Delta tables, the engine drops back to DirectQuery against the underlying Fabric Warehouse or Lakehouse SQL endpoint. The report keeps working — that's the point of the safety net — but you lose the in-memory performance you were counting on. Fallback is silent by design. Nothing in the report UI tells the end user it happened.
The usual triggers
In practice, fallback tends to come from a short list of causes:
- Delta tables with too many row groups or small files, past the framing thresholds Fabric enforces
- Use of unsupported column types or features (certain calculated columns, some security configurations)
- The model exceeding the guardrails for the capacity SKU it's running on (max table or model size)
- A table that hasn't yet been framed after a Delta write, so the model temporarily reads through
How to catch it before your users do
Don't wait for a complaint. Two habits catch this early:
If a report that used to feel instant now has a noticeable visual load time, check fallback before you check DAX.
First, watch the Fabric capacity metrics app for DirectQuery activity against semantic models you expect to be Direct Lake. A spike there, correlated with a specific model, is your signal. Second, use the Direct Lake guardrails diagnostics — either via the semantic model's analyze in Excel connection or DAX Studio's query plan — to confirm whether a given query resolved in-memory or fell through.
Keeping models in Direct Lake mode
Most of the fix is upstream, in how the Lakehouse or Warehouse writes data. Schedule regular table maintenance (OPTIMIZE/VACUUM equivalents) to keep file counts and row group sizes within the framing limits. Avoid wide tables with very high column counts where you don't need them. And size your capacity with headroom — guardrail limits scale with the SKU, so a model that fits comfortably on an F64 might trigger fallback constantly on an F8.
None of this is exotic. It's the same discipline import-mode modelers have always needed — keep your tables clean and your model lean — just with a new failure mode if you skip it.