What it does

Direct Lake is a table storage mode that reads Delta tables in OneLake directly and processes queries with the VertiPaq engine, the same engine Import uses. Refresh is a metadata operation called framing — it points the model at the current version of the Delta files rather than copying data, so it takes seconds.

Key facts

• Direct Lake needs a Fabric capacity licence. Import and DirectQuery run on any Power BI or Fabric licence, including free.
• There are two flavours. Direct Lake on OneLake reads Delta tables from one or more Fabric sources and never falls back to DirectQuery. Direct Lake on SQL goes through a single source's SQL analytics endpoint and falls back to DirectQuery when it can't read the Delta table directly, controlled by the Direct Lake behavior model property.
• Direct Lake on OneLake can be combined with Import tables (via Power BI web modelling) and with DirectQuery tables (via XMLA). Direct Lake on SQL can't be part of a composite model at all.
• Per-SKU guardrails apply: parquet files per table, row groups per table, rows per table, maximum model size on disk, and a maximum memory ceiling. Most are evaluated per query; model size on disk is evaluated at model level.
• Exceed a guardrail and behaviour differs by flavour — Direct Lake on OneLake fails the refresh and the model can't be queried; Direct Lake on SQL falls back to DirectQuery if fallback is enabled, succeeding with a warning and slower queries.
• Calculated columns aren't supported (Microsoft lists them as coming for Direct Lake on OneLake). Calculated tables are in preview for Direct Lake on OneLake only. Calculation groups, what-if parameters and field parameters work in both.
• Hybrid tables, user-defined aggregations and model table partitions aren't supported — partitioning happens at the Delta table level instead.
• Complex Delta column types are unsupported, as are binary and GUID semantic types. String values are limited to 32,764 Unicode characters, and non-numeric floats such as NaN aren't supported.
• One-side relationship columns must contain unique values or queries fail outright.
• When the SQL analytics endpoint enforces row-level security, Direct Lake on OneLake does not apply it — access is governed by permissions on the OneLake files instead.

When to use / skip

Direct Lake is for IT-led, lake-centric builds where the gold layer already lives in OneLake and the data is too big to keep copying into an Import model. If that's the shape of the client's platform, it's the right answer and the refresh story alone justifies it. Skip it if the data preparation doesn't happen in the lake, if the model author can't write to the lakehouse, or if the model leans on calculated columns and hybrid tables — you'd spend the project reimplementing modelling logic upstream. It also isn't a replacement for a self-service analyst's Import model, and Microsoft says so directly.

Configuration decisions

• Direct Lake on OneLake or Direct Lake on SQL — this is the big one, because it fixes your composite model options, your fallback behaviour and your security model.
• Whether DirectQuery fallback stays enabled on Direct Lake on SQL. Disabling it makes failures loud and obvious instead of quietly slow.
• Where the transformation logic lives, given calculated columns aren't available. Spark, T-SQL, dataflows and pipelines are all on the table.
• How Delta tables are maintained — V-Order, row group sizing, file compaction — because Direct Lake performance is largely a function of how tidy the Delta tables are.
• Whether security is enforced through OneLake file permissions or SQL endpoint RLS, since the two flavours treat that differently.

Gotchas

• The most common surprise is silent fallback. Direct Lake on SQL over a non-materialised SQL view falls back to DirectQuery every time, and the client is now running the DirectQuery performance profile while believing they're on Direct Lake.
• Unoptimised Delta tables — lots of small parquet files after a chatty write process — will breach guardrails long before the row counts look alarming.
• Direct Lake on OneLake doesn't observe SQL-based row-level security. If the security model was built at the SQL endpoint, moving flavours quietly changes who can see what.
• The feature set is still moving. The Direct Lake overview page was last updated 15 June 2026 and Microsoft explicitly says the considerations and limitations list changes often — check it before you promise anything.
• The capacity guardrail table also lists P SKUs, but Microsoft is retiring the Power BI Premium per-capacity SKUs in favour of Fabric F SKUs. Read the current licensing guidance rather than the table alone.

Consultant notes

• Build a proof of concept. Microsoft recommends it in the docs, which is unusually direct for them, and it's the fastest way to find out whether the client's Delta tables are actually in good enough shape.
• Frame Direct Lake as a data platform decision, not a Power BI feature. If the client isn't investing in the lakehouse, the argument doesn't hold.
• Warn the client that "no refresh" is not the same as "no data engineering". The refresh cost moves upstream to whoever maintains the Delta tables.
• Check whether fallback has been happening in production. A model that looks fine in Desktop and crawls in the service is nearly always falling back for a reason you can find and fix.

---

Direct Lake changes fast — recheck the considerations and limitations list before quoting any restriction from this page.