Three ways a model gets its data
| Mode | Where the data lives at query time | Freshness | Speed | Needs refresh? |
|---|---|---|---|---|
| Import | In VertiPaq, in memory (a cached copy) | As of last refresh | Fastest | Yes — scheduled |
| DirectQuery | In the source; every visual issues live queries | Live | Source-dependent (often slow) | No cache, but metadata refresh |
| Direct Lake | OneLake Parquet, loaded on demand into memory | Near-live (follows the lakehouse) | Near-Import | No traditional refresh |
Import — the default and the fastest
Import loads data into the columnar VertiPaq engine. Queries are answered from memory, so it is fast and supports the full DAX surface. The cost: data is a snapshot as of the last refresh, the model is bounded by memory limits, and refresh must be scheduled and can fail (its own concept). Most models should be Import.
DirectQuery — live but constrained
DirectQuery leaves data in the source and translates each visual into a live query (SQL, etc.). Data is always current and there is no memory ceiling on the data itself, but:
- Performance is at the mercy of the source and the network — every slicer click is a round trip.
- Not all DAX/modelling features are supported, and it can hammer the source system.
- Concurrency and capacity CU consumption can spike.
Use it when data must be real-time or is too large to import, and the source is tuned for it.
Direct Lake — the Fabric-native path
Direct Lake is Fabric's answer: the semantic model reads Parquet files directly from OneLake (a lakehouse or warehouse), loading columns into memory on demand — Import-like speed with no data-copy refresh and near-live freshness. It requires the data to live in Fabric (OneLake) and runs on Fabric capacity. Under memory pressure or unsupported operations it can fall back to DirectQuery transparently — which quietly changes performance.
Failure modes
- DirectQuery on a slow source. Reports crawl and users blame Power BI; the source is the bottleneck.
- Import model outgrowing memory. Refresh fails or the model won't load once it exceeds the capacity/licence memory ceiling.
- Direct Lake silent fallback. A model quietly reverts to DirectQuery (memory limit, unsupported feature), and performance degrades with no obvious cause.
- Mixed/composite confusion. Composite models mixing modes create subtle correctness and RLS pitfalls.
What to watch (proofs)
- Storage mode per model/table: the admin scanner (
admin/workspaces/getInfo) reports each table's mode — the estate-wide Import/DirectQuery/Direct Lake census. - Refresh dependence:
Get-PowerBIDatasetrefresh history shows which models rely on scheduled refresh (Import) vs not. - Direct Lake fallback: capacity metrics and query diagnostics reveal DirectQuery fallback events on Direct Lake models.
- Source load: DirectQuery models hitting an on-prem source route through the gateway — cross-reference with gateway load (the refresh/gateway concept).