Live Incident · P1

Work the Incident

Step 1 of 4 — Work the Incident
Postmortem

Incident Resolved

Root causeSales_Fact → Delta table exceeds guardrails
Failure modeDirect Lake → Direct Query fallback
TriggerWeekend batch load pushed file/row-group count over the guardrail
DetectionEVALUATE TABLETRAITS() — DirectLakeFallbackInfo
ResolutionOPTIMIZE silver.sales_fact VORDER, then VACUUM

What To Monitor in Production

SignalWhy It Matters
Parquet file countGuardrail is 5,000 on F64 (1,000 on F2–F32, 10,000 on F512+) — rising count ahead of the line is the earliest warning
Row group countSame 5,000 guardrail on F64 — fragmentation from frequent small writes, independent of raw row count
Direct Query operationsA spike against a model configured for Direct Lake means a table already fell back
TABLETRAITS() on a scheduleThe exact, documented diagnostic — not a symptom, a confirmed cause

What Is a Direct Lake Fallback to Direct Query?

A Direct Lake fallback is when Fabric switches a semantic model from Direct Lake to Direct Query. Per Microsoft’s documented conditions, a table stays in Direct Lake mode only if all of the following are true: no row-level security (RLS) or dynamic data masking (DDM) at the SQL analytics endpoint, no object-level security (OLS) at the SQL endpoint, no reference to an unmaterialized SQL view, the table within its Fabric SKU’s Parquet file, row group, and row count guardrails, and the table already framed. If any one fails, the default DirectLakeBehavior setting (Automatic) falls back silently. Capacity memory pressure can also force fallback. EVALUATE TABLETRAITS() is the documented way to confirm which one applies, via the DirectLakeFallbackInfo column.

F64, this incident’s capacity, allows 5,000 Parquet files, 5,000 row groups, and 1.5 billion rows per table before a guardrail is crossed — see the full Fabric capacity requirements table on Microsoft Learn.

Fallback CauseHow To Fix It
Table isn’t framedRefresh the semantic model to frame the tables
Table is based on a SQL viewMaterialize the view as a Delta table
OLS defined at SQL endpointMove object-level security to the semantic model
RLS or DDM defined at SQL endpointMove row-level security to the semantic model
Delta table exceeds guardrailsRun OPTIMIZE and VACUUM; upgrade the SKU if still over
Capacity under memory pressureReduce concurrent workloads or upgrade the capacity SKU

Source: Microsoft Learn — How Direct Lake works, sections Diagnose fallback and Fix common fallback causes.

Production Playbook

Prevent This From Happening Again

Spark SQL — compact and reorder the table
OPTIMIZE silver.sales_fact VORDER — compacts small files and row groups back under Direct Lake’s guardrailVACUUM silver.sales_fact — removes the old files OPTIMIZE leaves behind

Checklist

  • Schedule OPTIMIZE right after every large batch load — not on a fixed weekly clock, immediately after the load that grows the table
  • Run EVALUATE TABLETRAITS() on your riskiest models regularly — it is the precise, documented diagnostic, not a guess from dashboard symptoms. See Cross-workload table maintenance and optimization for V-Order and row group guidance.
  • If compaction alone is not enough, consider the capacity SKU — Microsoft documents SKU increase as a valid option when a table still exceeds limits after optimization
Field Questions

Direct Lake Fallback to Direct Query: FAQ

Why did my Power BI report silently switch from Direct Lake to Direct Query?
Direct Lake on SQL requires several conditions to stay in Direct Lake mode: no row-level security (RLS) or dynamic data masking (DDM) at the SQL analytics endpoint, no object-level security (OLS) at the SQL endpoint, no reference to an unmaterialized SQL view, the table within its Fabric SKU’s Parquet file, row group, and row count guardrails, and the table already framed. If any one condition fails, the default DirectLakeBehavior setting (Automatic) silently falls back to Direct Query. Capacity memory pressure can also force fallback. There is no error and no alert.
How do I check why a Direct Lake model fell back to Direct Query?
Run EVALUATE TABLETRAITS() against the semantic model. The DirectLakeFallbackInfo column reports the fallback reason for each table directly, which is more precise than inferring fallback from the Capacity Metrics app alone.
How do I fix a Direct Lake fallback caused by row group or file guardrails?
Run OPTIMIZE with V-Order on the affected Delta table to compact small files and reduce row group count back under Direct Lake’s guardrail. Guardrails vary by Fabric SKU — for example, F64 allows 5,000 Parquet files, 5,000 row groups, and 1.5 billion rows per table. If the table still exceeds limits after compaction, increasing the capacity SKU is also a documented option.
Does Direct Lake on OneLake fall back to Direct Query the same way as Direct Lake on SQL?
No. Direct Lake on OneLake does not fall back to Direct Query at all. If guardrails are exceeded, refresh fails and the model cannot be queried until the Delta tables are optimized back within limits.
AJ
A.J. On-Call · UIG Data Lab

On-Call dramatizes real Microsoft Fabric production incidents, verified against Microsoft Learn and A.J.’s Fabric/Power BI research on UIG Data Lab. Every case is grounded in real, documented platform behavior, including the diagnostic commands.