Momentum One Academy · article
Direct Lake and Semantic Models in Microsoft Fabric
The production problem
A Fabric delivery often starts with a reasonable request: “Give leaders a dashboard that is fast, current, and uses the same definitions as our finance and operations teams.” The difficulty appears when the team tries to satisfy all three requirements at once. Import models can be fast, but they duplicate data and depend on refresh windows. DirectQuery can expose source changes quickly, but report performance depends on the source endpoint and the queries it receives. Meanwhile, a lakehouse can contain technically correct tables without exposing a reliable business vocabulary for measures such as revenue, margin, active customer, or on-time delivery.
Direct Lake is useful when the production architecture already has curated Delta tables in OneLake and the reporting layer needs interactive, semantic-model performance without importing the full data volume into a separate cache. It is not a replacement for data engineering or modeling. It moves more of the performance responsibility upstream: table layout, update patterns, permissions, capacity sizing, and model design all become part of the reporting product. Microsoft describes Direct Lake as a semantic-model table storage mode that reads Delta tables in OneLake and loads required columns into memory for analysis. 1
For Momentum One projects, the practical question is therefore not “Can we turn on Direct Lake?” It is “Which tables, security boundary, update contract, and user questions justify Direct Lake, and how will we prove that choice in production?”
The Fabric concepts that matter
OneLake is Fabric’s shared data foundation. Direct Lake works against Delta tables stored in OneLake, so the semantic model can consume the curated files rather than making a full second copy during every refresh. The model remains the business-facing contract: it defines relationships, measures, naming, hierarchies, and the slice-and-dice behavior that report authors and AI experiences rely on. 1
A semantic model should be treated as a governed analytical interface, not as a pile of tables. A useful model usually has a clear grain, a fact-and-dimension structure, explicit date logic, and measures whose names make sense to people who did not build the pipeline. This matters for ordinary reports, and it matters even more when a natural-language tool has to map “net sales last quarter” to the correct measure and filter.
Direct Lake has two important forms. Direct Lake on OneLake reads through OneLake APIs and does not use DirectQuery fallback. It supports multi-source composite modeling and OneLake security. Direct Lake on SQL uses the SQL analytics endpoint for discovery and permission checks and can fall back to DirectQuery when a query encounters unsupported conditions such as a SQL view, SQL-endpoint security, or capacity guardrails. Microsoft’s development guidance recommends choosing OneLake when consistent Direct Lake behavior, composite modeling, or OneLake security is the priority, and choosing SQL when the solution depends on delegated identity and SQL-endpoint security rules. 2 3
That distinction is operational, not cosmetic. A model that is nominally Direct Lake on SQL may deliver some visuals through DirectQuery. A model on OneLake will not quietly switch to DirectQuery; a condition that cannot be handled in Direct Lake can instead cause a query or visual to fail. Make that behavior part of the design decision and test it with representative users.
Architecture choices for a production workload
Start with the gold layer. Ingest and transform upstream using the Fabric tools that fit the workload, then expose a stable set of Delta tables for the semantic model. Do not use Direct Lake as an excuse to point a report at raw landing files. The model should consume tables with an intentional grain, useful keys, compatible data types, and only the columns needed for analysis. This reduces both query work and the amount of ambiguous metadata presented to report authors and AI tools.
Choose Direct Lake on OneLake when most of the following are true:
- The source is one or more Fabric items whose OneLake storage resolves to valid Delta tables.
- The fact tables are large enough that a full Import copy is costly or impractical.
- The team wants fast interactive queries over a lake-centric architecture.
- The model needs an Import or DirectQuery table alongside large Direct Lake facts.
- The organization wants OneLake-level security or wants to avoid silent DirectQuery fallback.
Choose Direct Lake on SQL when the organization has a deliberate dependency on SQL analytics endpoint permissions, SQL views, or delegated identity. Accept that this route can fall back to DirectQuery and document the expected performance and freshness behavior. If the business requirement is “every query must prove it is using the in-memory path,” use a development gate that detects fallback before release rather than finding out from a slow executive dashboard.
Import is still a sensible choice for a small model, a self-service analyst who needs Power Query transformations inside the model, or a source that is not a good Delta-table candidate. DirectQuery remains relevant when the source must be queried directly or when freshness has priority over interactive performance. A composite model can be a pragmatic compromise: keep very large, curated facts in Direct Lake and keep a small exception table in Import or DirectQuery. Prototype this boundary with real report pages, not only a row-count estimate. Microsoft explicitly recommends a proof of concept for a Direct Lake decision. 1
Implementation guidance
1. Design the table and model contract together
Use a star-like model with clear relationships and measures. Convert unsupported or ambiguous upstream data types before the model consumes them. Prefer compact numeric keys and appropriately typed dates over string encodings where the business meaning permits. Hide technical columns that should not be used for analysis, and give tables, columns, and measures business-friendly names.
For Direct Lake performance, the Delta layout is part of the model. Microsoft recommends V-Order optimization, a small number of Parquet files, and large row groups. Data types, cardinality, segment count, and memory residency also affect cold-start and steady-state behavior. 4 A model can be logically elegant and still feel slow if the source table is fragmented into many small files or contains high-cardinality text where a compact type would do.
2. Pick an identity and security boundary before publishing
With SSO, Direct Lake evaluates the identity of the user querying the model. A fixed-identity cloud connection can be appropriate for an embedded or read-only consumer pattern where access is intentionally scoped to a service identity. These choices change what the source must grant and what a report consumer can see, so test them with a Viewer, a content author, and an administrator—not only with the model owner. 5
For Direct Lake on OneLake, OneLake security is the source-level boundary. SQL analytics endpoint RLS or OLS is not a substitute for that boundary because OneLake mode does not use the SQL endpoint to check permissions. For Direct Lake on SQL, SQL-endpoint RLS can trigger DirectQuery fallback, while SQL-endpoint OLS or column restrictions can cause errors when a query touches protected objects. Prefer one clearly owned security design, apply least privilege, and test both allowed and denied cases before production. 5
3. Treat refresh as framing, not as an Import reload
A Direct Lake semantic-model refresh normally performs framing: it reads Delta metadata and establishes the point in time from which subsequent column loading can occur. It does not mean that every row has been copied into the semantic model. Direct Lake then loads the columns required by queries on demand, a process Microsoft calls transcoding. 2
That creates a useful production control. If the pipeline writes several related tables, disable automatic updates when necessary, finish the data preparation, validate the load, and then frame the model once. If low latency is more important than a coordinated release boundary, the model-level “Keep your Direct Lake data up to date” setting can automatically frame changed tables. Remember that data added after the last successful framing is not necessarily visible to every query until the next framing operation.
A related failure mode is aggressive Delta cleanup. A framed model can still reference the Parquet files associated with its Delta version. Do not vacuum away files that the model needs before framing it to a newer version; coordinate table maintenance and model updates. 4
4. Make fallback observable
For Direct Lake on SQL, use Automatic in a user-facing production model only when continuity is more important than guaranteeing the in-memory path. Use DirectLakeOnly during development or performance certification to make unsupported conditions fail loudly. DirectQueryOnly is useful as a comparison baseline when measuring the cost of fallback. Microsoft documents the following TOM/C# configuration pattern for disabling fallback:
// Disable fallback to DirectQuery mode.
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly;
database.Model.SaveChanges();
The property applies to Direct Lake on SQL. For a quick table-level diagnosis, run the DAX query below against the semantic model and inspect the DirectLakeFallbackInfo column; None indicates that the table is using Direct Lake.
EVALUATE TABLETRAITS()
Both examples are diagnostic or configuration tools, not substitutes for a representative workload test. 2
Copilot and Data Agent: useful only after the model is trustworthy
Copilot in Fabric is an assistive layer across several workloads, including Power BI, notebooks, Data Warehouse, and Real-Time Intelligence. Its experiences are workload-specific, administrator-controlled, and affected by capacity and regional settings. Treat generated SQL, DAX, KQL, summaries, and code as suggestions to review. Copilot can accelerate a capable team; it does not turn an unclear model or an ungoverned data source into a reliable product. 6
A Fabric data agent is a configurable conversational analytics artifact. It can use sources such as lakehouses, warehouses, KQL databases, and Power BI semantic models, then generate read-only SQL, KQL, or DAX queries against the selected source. The requesting user’s permissions remain relevant; sharing the agent does not automatically grant access to its underlying data. 7
This is where Direct Lake and semantic-model discipline pay off. When a data agent uses a semantic model, the DAX generation path relies on model metadata and the model’s “Prep for AI” configuration. Configure a focused AI data schema, select only relevant tables and measures, define business terminology and metric preferences, and add verified answers for recurring high-value questions. Data-agent-level instructions are not the right place for semantic-model-specific DAX guidance according to Microsoft’s current best-practice guidance. 8
For a Momentum One production rollout, build an evaluation set before inviting a broad audience. Include questions with synonyms, ambiguous metric names, fiscal periods, security boundaries, and “show your work” expectations. Inspect the generated DAX for correctness, compare answers with an approved result, and keep a human owner for metric definitions. A data agent should make governed insight easier to request; it should not become an unreviewed path around the semantic model.
Trade-offs and failure modes to design for
“Direct Lake means real-time” is false. Automatic updates can reduce latency, but framing still creates a model baseline. If the source is in the middle of a multi-table load, users may see an incomplete state unless the pipeline and framing are coordinated. 2
Silent fallback hides an architecture defect. A report can remain functional while some queries run through DirectQuery. That can create an inconsistent user experience: one page is fast after warm-up, another is slow because it touches a view or a security rule. Test with DirectLakeOnly, inspect fallback information, and retain a known DirectQuery baseline.
File health is a user-experience concern. Small-file proliferation, destructive overwrites, excessive row groups, and memory pressure can force repeated loading or prevent Direct Lake from operating within capacity guardrails. Use incremental patterns where possible, schedule optimization, and size capacity from observed concurrency rather than the model’s compressed file size alone. 4
Security can be correct in one path and wrong in another. OneLake security, semantic-model RLS, and SQL-endpoint rules have different scopes. A user who is allowed to query a semantic model is not automatically allowed to query every underlying item, and a model-level rule does not protect a separate access path. Test report viewing, model building, direct source access, and data-agent access as separate scenarios. 5 7
AI can be precise and still answer the wrong question. A syntactically valid DAX query can select Gross Sales when the business means Net Sales. Focused schemas, clear names, verified answers, and human evaluation reduce this risk; they do not remove the need for review. 8
Production checklist
Before release, confirm that the source tables are curated Delta tables with a documented grain, compatible data types, stable keys, and an update pattern that will not create an avoidable small-file problem. Confirm whether the model is Direct Lake on OneLake or Direct Lake on SQL, and record the expected fallback policy.
Validate a cold query, a warm query, a post-framing query, and a concurrent-user test. Measure representative report pages rather than a single benchmark visual. Use fallback diagnostics and capacity monitoring to explain slow results. Test SSO and fixed-identity behavior, including denied access, RLS, OLS, and cross-workspace source access.
Define the framing contract with the pipeline: which job writes which tables, when data is considered complete, who triggers or owns framing, and how Delta optimization and vacuuming are coordinated. Document the recovery action for a failed frame, missing source table, schema drift, capacity pressure, and a fallback that appears unexpectedly.
For Copilot and the data agent, verify tenant and capacity eligibility, regional data-processing requirements, permitted sources, least-privilege access, and the human review path. Prepare a small question-and-answer test set, inspect generated DAX/SQL/KQL, and publish only after the results meet an agreed accuracy bar. Re-test after changing a measure, relationship, source table, AI schema, or agent instruction.
Workshop connection
In Module 8, use Direct Lake as the point where the pipeline becomes a governed product. Bring a curated Delta table into a semantic model, choose the OneLake or SQL route explicitly, and write down why. Then test framing and warm-up behavior, force a known fallback condition in a safe development workspace, and use the diagnostic output to explain what happened. Finish by asking Copilot or a data agent a business question that depends on a named measure, checking the generated query, and correcting the model metadata or Prep for AI configuration rather than patching the answer manually.
That sequence is the Momentum One production habit: make the data path fast, make the semantic contract explicit, make security testable, and make AI answer from the same governed definitions that power the report.
Ready to turn the pattern into a repeatable delivery? Join the Momentum One Academy Fabric Production Workshop.
References
Plan your workshop