Direct Lake and Incremental Refresh

What it is

Direct Lake is a storage mode in which a semantic model reads Delta tables in OneLake directly, loading the columns a query needs into memory. It gives near Import speed without copying data into the model on a schedule.

Incremental refresh is the large-model technique for Import models. Instead of reloading every row, the model is split into date partitions and only the recent ones are refreshed.

How it works

Framing and refresh behaviour

A Direct Lake model does not import data. Its refresh, called framing, is a quick metadata operation that points the model at the latest version of each Delta table. After framing, the next queries load the columns they need from the Delta files.

The model setting Keep your Direct Lake data up to date reframes automatically when the Delta tables change. It is on by default.

Turn it off when a load writes several tables in steps and reports must not show a half-finished load. Then reframe the model yourself at the end of the load, for example with a semantic model refresh step in the data pipeline, or on a schedule.

The first queries after framing can be slower because columns must be loaded again into memory. Keeping Delta tables well maintained, with fewer, larger files and V-Order, also helps Direct Lake performance.

DirectQuery fallback

Direct Lake on the SQL analytics endpoint can fall back to DirectQuery, sending SQL queries to the endpoint instead of reading Delta files. Fallback happens when, for example:

• a table exceeds the guardrails for the capacity size, such as the per-table limits on rows, Parquet files or row groups;
• the model uses a SQL view instead of a Delta table;
• the SQL analytics endpoint has row-level security, object-level security or dynamic data masking on a table the model uses.

The model property DirectLakeBehavior controls this. You set it in the model's Properties pane in Model view, or with an XMLA tool such as Tabular Editor:

Choose DirectLakeOnly when predictable performance matters more than always getting an answer, so that a slow fallback never hides a design problem.

Direct Lake on OneLake vs on SQL analytics endpoint

Choose Direct Lake on OneLake when the model combines tables from several lakehouses or warehouses, or when security is defined with OneLake security. Choose Direct Lake on SQL analytics endpoint when the model needs SQL views or relies on SQL permissions and you accept DirectQuery fallback.

Incremental refresh

Incremental refresh applies to Import tables (and to hybrid tables with a DirectQuery partition). You set it up in Power BI Desktop:

1. Create two Date/Time parameters named exactly RangeStart and RangeEnd.
2. Filter the table's date column with them, inclusive on one side and exclusive on the other.
3. Define the policy on the table: how much history to store and how much to refresh.

Table.SelectRows(Source, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)

The filter must fold to the source, so the source receives a query for each partition's date range. The first refresh in the service creates the partitions and loads all history; later refreshes touch only the recent window.

A worked example

A model has 4 billion sales rows in a lakehouse and a separate 600 million row Import model on Azure SQL Database.

1. For the lakehouse data, build a Direct Lake on OneLake model, because it also needs a product table from another team's warehouse. A 4 billion row table needs F256 or larger, whose guardrail is 6,000 million rows per table; on a smaller SKU, Direct Lake on OneLake refresh fails rather than falling back.
2. The nightly load writes facts then dimensions, so turn off automatic updates and reframe the model as the pipeline's last step.
3. For the Azure SQL model, add RangeStart and RangeEnd, keep 5 years, refresh the last 10 days, and turn on Detect data changes on LastModified.
4. Deploy later changes to that model through the XMLA endpoint so the partitions are kept.

How the exam asks about this

• "A Direct Lake model must never send queries to the SQL analytics endpoint." Set DirectLakeBehavior to DirectLakeOnly, or use Direct Lake on OneLake.
• "A model needs tables from two lakehouses in Direct Lake mode." Direct Lake on OneLake.
• "Refresh only the last seven days of a large Import table." Incremental refresh with RangeStart and RangeEnd.