Direct Lake in Microsoft Fabric: what it changes for Power BI

Direct Lake lets a Power BI semantic model read Delta tables straight from OneLake into memory, instead of copying the data in on a refresh schedule. Reports keep Import-mode speed, new data appears within seconds of landing, and nothing is duplicated. The catch: it needs a Fabric capacity and data prepared in a lakehouse or warehouse first.

For most of Power BI's life you had two choices. Import mode copies the data into the model on a schedule: fast to query, but only as fresh as the last refresh, and refreshes get slower as the data grows. DirectQuery leaves the data at the source and asks the database every time a visual loads: always current, but usually slower. Direct Lake is the third option that Microsoft Fabric added, and it changes the trade-off for anyone whose data already sits in OneLake. This guide explains how it works, what it costs and when it is worth it, with every behaviour checked against Microsoft Learn as of October 2026.

How does Direct Lake actually work?

Three mechanisms do the work, and it helps to know their names because they turn up in every error message and settings page.

Transcoding (column loading). A Direct Lake model holds no data until someone asks for it. Microsoft's How Direct Lake works page explains that when a query arrives, the model works out which columns it needs, including those used by relationships and measures, and loads any that are not already in memory from the Parquet files behind the Delta table. Loaded columns stay resident until they are evicted: after the data changes, after a period of no use, or under memory pressure on the capacity.

Framing. A Direct Lake "refresh" does not copy data. It reads the Delta table's metadata and points the model at the latest Parquet files, which Microsoft says usually takes a few seconds. The point of the last framing is the version of the data your reports see, which gives you control: a half-finished overnight load does not leak into the Monday dashboard if you only frame once it has finished.

Automatic updates. A model-level setting called Keep your Direct Lake data up to date is on by default. With it on, the model frames itself whenever the underlying Delta tables change. Turn it off when you want to expose new data only after an ETL job completes, then trigger the refresh on a schedule or through the API.

The query engine underneath is the same VertiPaq engine that serves Import mode, which is why the speed is comparable. DirectQuery, by contrast, translates every DAX query into SQL for the source database to answer.

How is Direct Lake different from Import and DirectQuery?

The Direct Lake overview on Microsoft Learn has a full capability matrix. The rows that matter most to a small team are these:

	Import	DirectQuery	Direct Lake
Licensing	Any Power BI or Fabric licence	Any Power BI or Fabric licence	Fabric capacity (F SKU) only
Where the data lives	Copied into the model	Stays in the source	Delta tables in OneLake
Freshness	As of last scheduled refresh	Live	As of last framing, usually seconds
Query engine	VertiPaq (in memory)	The source database	VertiPaq (in memory)
Power Query transformations in the model	Yes	Limited	No: prepare data upstream
Data sources	Any connector	Connectors that support DirectQuery	Fabric items with Delta tables
Gateway for on-premises data	Yes	Yes	Not supported: cloud connections only

The row that catches people out is the Power Query one. Direct Lake depends on data preparation happening in the lake, using notebooks, warehouse SQL, dataflows or pipelines. If your current model does its cleaning in Power Query, that logic has to move upstream before Direct Lake can use the result. Microsoft's own suggestion for an analyst who can't change the lakehouse is to add Import tables for the bits they need to shape themselves.

What are Direct Lake on OneLake and Direct Lake on SQL?

There are two flavours, and the choice affects behaviour more than the similar names suggest.

Direct Lake on OneLake reads Delta tables directly through OneLake. It can draw on more than one Fabric item, can sit alongside Import tables in the same model, supports calculated columns and calculated tables over Direct Lake tables (both in preview), and never falls back to DirectQuery. Microsoft's Develop Direct Lake semantic models guidance recommends it for new models, and it is the only option when you create a model from Power BI Desktop or the OneLake catalog.

Direct Lake on SQL connects through a single lakehouse or warehouse's SQL analytics endpoint. It can use SQL views and security rules defined in SQL, but when it meets a non-materialised view, SQL row-level security or a table over the capacity's guardrails, queries fall back to DirectQuery and slow down. A model property, Direct Lake behavior, controls that: Automatic (the default) falls back silently, DirectLakeOnly makes the query fail instead, and DirectQueryOnly forces DirectQuery so you can measure the difference. To find tables that are falling back, Microsoft suggests running EVALUATE TABLETRAITS() in DAX query view and reading the DirectLakeFallbackInfo column.

Our view: start new models on OneLake unless you have a firm reason to keep security rules in the SQL endpoint. A fallback you don't know about is a performance problem nobody can explain.

What does Direct Lake cost to run?

Direct Lake itself has no separate price. What it needs is a Fabric capacity, and that is where the money goes. Checked against the Azure Retail Prices API on 26 October 2026, UK South capacity costs £0.1585 per capacity-unit hour on pay-as-you-go and £825.69 per capacity unit per year on a one-year reservation. That makes the smallest capacity, an F2, about £231 a month pay-as-you-go or about £138 a month reserved, as of October 2026. Our Fabric pricing guide covers every SKU and the pause-overnight trick.

Two less obvious costs matter more for a small team:

• Viewer licences don't go away below F64. Microsoft's licensing page states that on F SKUs smaller than F64, each person viewing Power BI content needs a Pro, Premium Per User or individual trial licence. Free-licence viewers only work from F64 upwards. So an F2 plus Direct Lake adds cost on top of your Pro licences rather than replacing them; Power BI licensing explained sets out the per-user side.
• Small capacities have hard guardrails. On F2, F4 and F8 Microsoft lists limits of 300 million rows and 1,000 Parquet files per table, a 10 GB maximum model size and 3 GB of memory for paging data in, as of October 2026. On Direct Lake on OneLake, going over a per-table guardrail makes the refresh fail and the model can't be queried until the Delta tables are optimised. On Direct Lake on SQL, queries fall back to DirectQuery instead.

For most SMEs those limits are generous: a sales table rarely reaches 300 million rows. The Parquet file count is the one to watch, because frequent small appends create many small files. Running OPTIMIZE on the Delta table compacts them, and Microsoft's fallback-fix table recommends exactly that.

When should an SME actually use Direct Lake?

Microsoft describes the primary use case as IT-driven analytics on lake-centric architectures with large volumes of data, and says Import and DirectQuery are still the right choice for some scenarios. In our view that translates into a fairly short checklist for a small business. Direct Lake is worth it when:

1. Your data already lands in a Fabric lakehouse or warehouse, for example because you combine several systems there, as described in our data lakehouse explainer.
2. Import refreshes have become a problem: they run long, hit the eight-a-day limit on Pro, or copy the same large table into several models.
3. People need data that is minutes old, not overnight, and DirectQuery against the source is too slow or too heavy on that system.
4. You already pay for a Fabric capacity for other workloads, so the marginal cost is close to zero.

It is usually the wrong choice when the data is a few million rows from Excel, SharePoint or an accounting package, the team has no Fabric capacity, and an overnight refresh is fine. Import mode on Pro licences does that job well and costs less. If you're unsure whether your reports are slow because of the storage mode at all, measure first with the steps in our Power BI performance tuning guide: a badly shaped model is slow in every mode.

How do you build your first Direct Lake model?

A sensible first project, following Microsoft's advice to prototype before committing, looks like this:

1. Prepare the tables in the lake. Load and clean the data into Delta tables in a lakehouse or warehouse, shaped as a star schema: facts and dimensions, matching data types on relationship columns and unique keys on the one side. Microsoft notes that queries fail if a one-side column contains duplicates, and that web modelling doesn't validate relationship choices for Direct Lake models, so get this right in the lake.
2. Create the semantic model. In Power BI Desktop, or from Create and then the OneLake catalog in the Power BI service, pick the tables. Both routes create a Direct Lake on OneLake model. You can't create one in My workspace, and the model must be in the same region as its data source.
3. Mark a proper date table. Auto date/time relationships aren't supported on Direct Lake on SQL, and a marked date table is good practice anyway.
4. Decide on automatic updates. Leave Keep your Direct Lake data up to date on for simple models; switch it off and schedule the refresh if loads run in stages.
5. Check the connection. For row-level security, Microsoft strongly recommends a fixed-identity cloud connection. If you promote models through deployment pipelines, note that data source rebinding rules are supported on Direct Lake on SQL but not on Direct Lake on OneLake, as of October 2026.

Existing Import models don't need rebuilding to get some of the benefit. Microsoft's OneLake integration can write Import tables out to Delta tables in OneLake, so notebooks and SQL can reuse them, and Microsoft recommends this as a quick first step before any redesign. Our guide to Power BI semantic models covers the model layer that all three modes share.

If you're weighing up a move to Fabric and want someone to tell you plainly whether Direct Lake would pay for itself on your data, that is the kind of question our Power BI and Fabric consultancy answers, alongside the pipeline work in data engineering. See all our data services.

Frequently asked questions

What is Direct Lake in Power BI?

Direct Lake is a storage mode for Power BI semantic model tables in Microsoft Fabric. The model reads Delta tables straight from OneLake into memory when a query needs them, so reports run on the same VertiPaq engine as Import mode without a scheduled refresh that copies all the data.

Does Direct Lake work with a Power BI Pro licence?

Not on its own. Microsoft lists Direct Lake as Fabric capacity (F SKU) only. On a capacity smaller than F64, everyone who views the reports still needs a Pro or Premium Per User licence; from F64 upwards, viewers with a free licence and a viewer role can open them.

Is Direct Lake faster than Import mode?

Usually about the same once data is in memory, because both use the VertiPaq engine. The first query that touches a column is slower while Direct Lake loads it from OneLake. The real gain is freshness and refresh cost, not query speed, and Direct Lake normally beats DirectQuery.

What is the difference between Direct Lake on OneLake and Direct Lake on SQL?

Direct Lake on OneLake reads Delta tables directly, can combine several Fabric sources and Import tables, and never falls back to DirectQuery; Microsoft recommends it for new models. Direct Lake on SQL goes through one SQL analytics endpoint and falls back to DirectQuery for SQL views or SQL-level security.

Should a small business switch its Power BI reports to Direct Lake?

Only if the data already lives, or should live, in a Fabric lakehouse or warehouse. For a few million rows from Excel, SharePoint or an accounting system, Import mode on Pro licences is simpler and cheaper. Direct Lake earns its place when refresh windows, data size or duplicated copies start to hurt.

---

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.