Two Flavors of DirectLake: Over SQL vs. Over OneLake (and How to Switch Without Surprises)

DirectLake has a way of sounding wonderfully simple: “Power BI, but it reads the lake directly.” Then you build two semantic models that both say DirectLake, and they behave… differently. One falls back to DirectQuery when you least expect it. Another refuses to touch your SQL views. Security works for you, but not for your report consumers. Suddenly, “DirectLake” feels less like a feature and more like a riddle.

The good news: this is explainable. And once you understand the two flavors—DirectLake over SQL and DirectLake over OneLake—you can choose deliberately, design around the trade-offs, and even switch between them when you have to.

In this post, I’ll demystify what each option really means, lay out the positives and negatives, explain when you’d use each (and why), and show how to switch using Semantic Link Labs—including what can break when you flip the switch.

What “over SQL” and “over OneLake” actually means

Both options are still Direct Lake storage mode: VertiPaq loads column data on-demand from Delta tables stored in OneLake. The difference is the “control plane” the semantic model uses for:

• Discovering tables and views
• Permission checks
• Fallback behavior when Direct Lake can’t load data

Microsoft’s own documentation describes Direct Lake as having two table storage options: Direct Lake on OneLake and Direct Lake on SQL endpoints.

Here’s the short version:

Decision point	DirectLake over OneLake	DirectLake over SQL
Primary path	Reads Delta tables directly via OneLake	Uses the SQL analytics endpoint for discovery & permission checks
Fallback	No DirectQuery fallback (Direct Lake or error)	Can fall back to DirectQuery in specific cases
Scope	Multi-source (can span multiple Fabric items)	Single-source (one lakehouse/warehouse endpoint)

These aren’t small implementation details—they shape how you model, secure, and operate your solution.

DirectLake over SQL

What it is

DirectLake over SQL (Microsoft calls this Direct Lake on SQL endpoints) is anchored to a single Fabric SQL analytics endpoint (Lakehouse SQL endpoint or Warehouse). The SQL endpoint is used for Delta table and SQL view discovery and permission checks, and the model can fall back to DirectQuery when Direct Lake can’t load from a Delta table (for example, when the source is a SQL view, or SQL-based granular access control is involved).

Positives (why you’d pick it)

DirectLake over SQL is a strong choice when you want a “warehouse-like” experience with a safety net:

• Views are in play. If your semantic model references SQL analytics endpoint views, Direct Lake can’t load them as files—so the model will typically fall back to DirectQuery to make the view work.
• Fallback can save you. When a query can’t use Direct Lake (views, certain security situations, guardrails), DirectQuery fallback can keep reports functional—though potentially slower.
• SQL permission model alignment. Permission checks happen through the SQL endpoint: users can be authorized through lakehouse/warehouse access plus SQL endpoint permissions (SELECT), without necessarily having direct file permissions in OneLake.

Negatives (the trade-offs)

DirectLake over SQL is also the flavor most likely to surprise you operationally:

• You’re dependent on the SQL endpoint. Availability and performance of the SQL analytics endpoint now matter in ways the word “DirectLake” doesn’t advertise.
• Fallback can become your “hidden default.” If you frequently trigger fallback, you’ve effectively built a partial DirectQuery model—performance, concurrency, and behavior can change per-query. Microsoft explicitly recommends designing to avoid fallback where possible.
• Single-source constraint. You can’t build a true multi-source composite model using Direct Lake on SQL endpoints.
• Shortcuts + delegated identity gotcha. When accessing OneLake shortcuts through semantic models using DirectLake over SQL (or certain T‑SQL engines) in delegated identity mode, the calling user’s identity is not passed to the shortcut target—item owner identity is used instead. Microsoft’s guidance is to use DirectLake over OneLake (or T‑SQL in user identity mode) to resolve this.

DirectLake over OneLake

What it is

DirectLake over OneLake (Microsoft calls this Direct Lake on OneLake) connects directly to Delta tables in OneLake. It can use one or more Fabric data sources backed by Delta tables and does not fall back to DirectQuery via the SQL endpoint.

This is the “no middle layer” option: fewer moving parts, but also fewer escape hatches.

Positives (why you’d pick it)

DirectLake over OneLake is the direction the platform is clearly investing in:

• Multi-source modeling. A single semantic model can pull Direct Lake tables from multiple Fabric items (as long as they’re Delta-backed).
• Composite models with Import are supported. You can mix Direct Lake tables with Import tables (and in some tooling scenarios, DirectQuery tables) in one semantic model—useful for small dimensions or helper tables.
• No fallback ambiguity. If the query is served, it’s served as Direct Lake. You don’t get “it was fast yesterday, why slow today?” because a view got touched and triggered fallback.
• OneLake-centric security integration. Permission checks use OneLake APIs and can integrate with OneLake Security for OLS/RLS enforcement.
• Shortcuts behave more like you’d expect. For internal shortcuts, the effective identity must have permission in the target location—no silent “owner identity” delegation.

Negatives (the trade-offs)

You’re choosing clarity and capability over flexibility:

• It’s still marked public preview in Microsoft’s documentation (as of Oct 2025). Creation requires enabling a tenant setting (“Users can create Direct Lake on OneLake semantic models (preview)”).
• No DirectQuery fallback—so unsupported things just fail. If you need SQL endpoint views, non-materialized views aren’t supported as Direct Lake on OneLake tables. You’ll need to materialize them as Delta tables (for example, via a lakehouse materialized view) or use another storage mode.
• Security expectations can shift. If you were relying on SQL endpoint row-level security, note that Direct Lake on OneLake requires file access in OneLake and does not apply SQL-based RLS from the SQL endpoint. That’s not inherently “less secure”—it just means you must enforce the rules in OneLake Security or the semantic model, not in the SQL endpoint.

When you’d use each (and why)

If you’re building standards for a Fabric program, this is the decision I’d encourage teams to make explicitly—not accidentally.

Use DirectLake over SQL when:

• You must rely on SQL endpoint objects such as views, and you’re comfortable with (or intentionally choosing) DirectQuery fallback behavior.
• Your governance model is centered on SQL endpoint permissions and you want authorization to be driven there (even though Direct Lake still reads the Delta files behind the scenes).
• You want a single, database-like anchor point for the model and are designing within the single-source constraint.

Use DirectLake over OneLake when:

• You want the model to span multiple Fabric items (domain-aligned lakehouses/warehouses) without forcing everything into one SQL endpoint boundary.
• You want to build a true composite semantic model (Direct Lake facts + small Import dimensions, etc.).
• You want security and access control to align with OneLake Security and avoid SQL endpoint OLS/RLS limitations that can force fallback in the SQL flavor.
• You’re using shortcuts and need identity behavior that matches least-privilege expectations (and avoids “owner identity” delegation surprises).

Switching between them with Semantic Link Labs

Sometimes you inherit a semantic model that picked a flavor for you. Sometimes deployment constraints force your hand. Sometimes you need to validate performance or security behavior in both modes before you commit.

This is where Semantic Link Labs (the semantic-link-labs package, imported as sempy_labs) earns its keep: it can update the shared expression that defines the Direct Lake connection and optionally switch whether it uses the SQL endpoint.

Step-by-step: flip the model connection

1. Install Semantic Link Labs in a Fabric notebook

%pip install semantic-link-labs

2. Import and run the connection update

import sempy_labs as sl

sl.directlake.update_direct_lake_model_connection(
    dataset="Sales Semantic Model",
    workspace="BI - Dev",
    source="GoldLakehouse",
    source_type="Lakehouse",          # or "Warehouse"
    source_workspace="Data - Dev",
    use_sql_endpoint=False            # False = DirectLake over OneLake
)

Setting use_sql_endpoint=False tells Semantic Link Labs to generate the expression without using the SQL endpoint—i.e., switch to DirectLake over OneLake. Setting it to True switches to DirectLake over SQL.

3. Optionally update only certain tables
   If your semantic model has multiple table expressions, you can target specific tables via the tables parameter (string or list).

sl.directlake.update_direct_lake_model_connection(
    dataset="Sales Semantic Model",
    workspace="BI - Dev",
    source="GoldLakehouse",
    source_type="Lakehouse",
    source_workspace="Data - Dev",
    use_sql_endpoint=True,           # True = DirectLake over SQL
    tables=["Sales", "Customers"]
)

A practical workflow tip

Treat this like a controlled schema change:

• Do it first in a dev workspace.
• Keep a rollback path (version history / git integration / exported definition).
• Validate with a small set of “known good” report pages and security test users.

This is especially important because the switch isn’t just performance-related—it can change what objects are supported and how permissions are evaluated.

What might break when you switch

This is the part that’s easy to underestimate. Flipping use_sql_endpoint is simple; ensuring the model still behaves the way the business expects is the real work.

Here are the main fault lines:

• SQL views (and anything relying on them). Direct Lake on OneLake doesn’t support creating a Direct Lake table from a non-materialized SQL view. If your model depended on views working via fallback, moving to OneLake mode can break those tables/queries unless you materialize them as Delta-backed objects.
• Fallback-dependent “success.” If your SQL-flavor model has been quietly succeeding because it falls back to DirectQuery, moving to OneLake flavor removes that safety net. The same DAX can now error instead of falling back. Conversely, moving from OneLake to SQL can introduce fallback paths you didn’t previously have to monitor.
• Security and permissions drift.
  • SQL flavor permission checks happen via the SQL endpoint; users may not need direct file permissions.
  • OneLake flavor checks via OneLake APIs/OneLake Security; users may need Read/ReadAll permissions or OneLake security role membership.
  • If you relied on SQL endpoint RLS/OLS, note that Direct Lake doesn’t support SQL endpoint OLS/RLS without falling back (SQL flavor) and SQL-based RLS isn’t applied in OneLake flavor—so you must enforce access rules in OneLake Security and/or the semantic model.
• Shortcuts identity behavior. DirectLake over SQL (delegated identity mode) can delegate access via the calling item owner’s identity rather than the calling user for shortcut targets; OneLake flavor aligns more directly with the effective identity needing permission at the target. This can change who can see what, and it can change in ways that look like “it works for me but not for them.”
• Multi-source/composite model constraints. If your model uses multiple sources or mixes Import tables (a common advantage of OneLake flavor), switching to SQL flavor may not be feasible without restructuring—because SQL flavor is single-source and doesn’t support the same composite patterns.

Closing: choose the flavor, don’t inherit it

DirectLake is not one thing. It’s a storage mode with two distinct “attachment points”:

• Over SQL gives you views and fallback, but adds SQL endpoint dependency, single-source constraints, and the risk of “silent DirectQuery.”
• Over OneLake gives you multi-source modeling, cleaner OneLake security alignment, and fewer moving parts—but removes fallback and demands you materialize what you want to query.

If you’re building on Fabric at enterprise scale, that choice is architecture—not a checkbox.

The call to action is simple: pick a flavor intentionally, document why, and if you need to switch, use Semantic Link Labs with a clear test plan for views, fallback, and security.