How the two Direct Lake flavours differ in table discovery, permission checks, fallback and unsupported cases, and which one to choose.
From Ultra Transcenders DP-600 by Tony Rough (coming December 2026)
Both flavours read Delta the same way but differ in table discovery, permission checks and unsupported cases. Learn recommends Direct Lake on OneLake for new models.
| Capability | Direct Lake on OneLake | Direct Lake on SQL analytics endpoint |
|---|---|---|
| Sources | One or more Fabric items resolving to Delta tables (natively or via shortcuts) | A single item with a SQL analytics endpoint |
| Discovery and permission checks | OneLake APIs | SQL analytics endpoint |
| M connector in the model | AzureStorage.DataLake | Sql.Database or OneLake.SqlAnalytics() |
| DirectQuery fallback | Never | Yes, per DirectLakeBehavior |
| SQL views | Not supported as Direct Lake tables (use Import/DirectQuery or lakehouse materialised views) | Supported, but fall back |
| Composite in the same model | Yes: Import tables (web modelling), DirectQuery tables (XMLA tools) | No |
| Calculated columns / tables on Direct Lake data | Yes (preview; columns user context only) | No |
| Security | OneLake security roles, or Read plus ReadAll | Endpoint GRANT/RLS/CLS (RLS causes fallback) |
| KQL database, Cosmos DB in Fabric | Supported | Not supported |
| Deployment rules to rebind source | Not supported | Supported |
Neither supports hybrid tables, model partitions (partition the Delta table instead) or user-defined aggregations; neither works in My workspace, across regions or with Binary, GUID or complex Delta types. Choose Direct Lake on SQL when you depend on endpoint security in delegated mode, need SQL views, or want unsupported queries to fall back. Choose Direct Lake on OneLake for multiple sources, Import composites, OneLake security, calculated columns and predictable no-fallback behaviour.
| Created from | On OneLake | On SQL |
|---|---|---|
| Service: Create > OneLake catalog, or New semantic model on an item | Yes | No |
| Power BI Desktop: OneLake catalog > Connect | Yes | No |
| SQL analytics endpoint: New semantic model | Yes | Yes |
| XMLA tools or notebooks (semantic link) | Yes | Yes |
Desktop live edits Direct Lake models in the workspace: no local file or publish, changes save automatically, Report view is removed, and version history snapshots each session; export to PBIP for Git-friendly metadata. It needs the XMLA endpoint enabled and set to Read Write on the capacity, Write on the model, Viewer on the lakehouse and a paid licence; RLS roles are validated in the service, not Desktop. XMLA tools need compatibility level 1604 or higher. You can migrate an On SQL model to On OneLake in TMDL view by swapping Sql.Database(…) for AzureStorage.DataLake(“https://onelake.dfs.fabric.microsoft.com/<workspace ID>/<item ID>”), unless it uses SQL views.
By default Direct Lake uses SSO, so users need data access as well as model access. A cloud connection with a fixed identity (OAuth 2.0, service principal or workspace identity) and SSO off lets users query the model with no permission on the source.
| Scenario | On SQL | On OneLake |
|---|---|---|
| View reports (SSO) | Read on report and model; Read on item, SELECT on tables | Read on report and model; Read on item plus OneLake role or ReadAll |
| Build reports (SSO) | Build on model plus the data access above | Build on model plus the data access above |
| Users mustn’t touch the source | Fixed identity with Read and SELECT | Fixed identity with Read and role or ReadAll |
Model RLS and OLS don’t apply to users with Write on the model (workspace Admins, Members, Contributors), and, with SSO, users who can read the lakehouse can bypass model-only rules, so Learn favours OneLake security for cross-engine rules.
Common trap: Building reports on a lakehouse’s default semantic model - default semantic models haven’t been created automatically since September 2025, and existing ones were decoupled into independent models; create a semantic model explicitly and choose its Direct Lake flavour.
Common trap: Relying on a deployment pipeline to repoint a Direct Lake model at the next stage’s lakehouse - a deployed Direct Lake model still binds to the source stage’s item, and rebinding data source rules are supported only for Direct Lake on SQL.
This note is one section of Ultra Transcenders DP-600: Implementing Analytics Solutions Using Microsoft Fabric, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · DP-600 terms in the glossary · All DP-600 study notes
When each table storage mode fits a semantic model, based on data size, latency, source security and capacity.
What each Fabric workspace role can do across Power BI, data engineering, warehousing and real-time items.
Which items and settings a deployment copies or leaves alone, and how data source and parameter rules point each stage at its own data.
How data type, team skills, write needs and transactions decide between Fabric's lakehouse, warehouse, eventhouse and other stores.
What the Warehouse can do that a lakehouse's read-only SQL analytics endpoint can't, and when to use each.
The three many-to-many scenarios in a semantic model and the bridge-table or relationship design each one needs.
How data volume, transformation needs, skills and latency decide which Fabric tool should copy data into OneLake.