Dual Storage and Direct Lake
Leaf & Cup now has 40 branches and an Orders table of hundreds of millions of rows, kept in DirectQuery. The report works, but the branch and product slicers feel slow, because each slicer asks the database for its list. Meanwhile the new data team has started landing everything in Microsoft Fabric. Two more storage options exist for exactly these two situations.
The rule
Dual tables answer either way; Direct Lake reads lake tables straight into memory.
Composite models. A model does not need one storage mode for everything. You set the mode per table — in Model view, select the table, then Properties → Advanced → Storage mode. A model that mixes modes is called a composite model.
Dual. A Dual table is imported and able to act as DirectQuery. For each query, Power BI chooses:
- If the visual needs only Import or Dual tables — say, a slicer listing branch names — it is answered from the in-memory copy, instantly.
- If the visual combines the Dual table with a DirectQuery table — say, revenue by branch from Orders — the whole query goes to the source, where the join happens in one place.
Dual suits the small dimension tables that sit around a large DirectQuery fact. Because it keeps a copy, a Dual table still needs refreshing.
Direct Lake. A storage mode that belongs to Microsoft Fabric. The data lives as Delta tables (Parquet files with a transaction log) in OneLake, Fabric's shared data lake, inside a lakehouse or warehouse. Import copies data at refresh, and DirectQuery asks a database per click; Direct Lake does neither. When a column is needed, it is loaded straight from the lake files into memory. You get speed close to Import with freshness close to the lake itself.
A Direct Lake "refresh" is light: it simply points the model at the latest version of the Delta tables, which takes seconds. Direct Lake needs a Fabric capacity, and the data must already be Delta tables in OneLake. Some Direct Lake models can fall back to DirectQuery for queries they cannot serve from memory, which is slower.
The shortcut
Walk down this ladder and stop at the first yes:
- Is the data already in Fabric as Delta tables? → Direct Lake.
- Does it fit, with a few refreshes a day fresh enough? → Import.
- Otherwise: the big fact → DirectQuery, and the small dimensions around it → Dual.
The Orders fact
Hundreds of millions of rows that must be fresh to the minute. It stays in DirectQuery.
The trap is leaving the dimensions in Import beside a DirectQuery fact. The model still works, but Power BI cannot hand the join to the source in one piece, and relationships between the two groups are treated as limited, which is slower and behaves differently from normal ones.
Drills
Answer fast — trust the rule.
What is a model that mixes Import and DirectQuery tables called?
Products sits beside a DirectQuery Sales fact and feeds several slicers. Which storage mode suits Products?
Where must the data sit for a model to use Direct Lake?
A slicer lists branch names from a Dual Stores table, and no other table is involved. Where does the list come from?
What does refreshing a Direct Lake model mainly do?
Remember
- Dual tables answer either way; Direct Lake reads lake tables straight into memory.
- Ladder: Fabric Delta tables → Direct Lake; fits → Import; otherwise DirectQuery fact with Dual dimensions.
- Trap: Import dimensions beside a DirectQuery fact create slower, limited relationships.
