Semantic Models: Storage Modes
Import, DirectQuery, or Direct Lake? The storage mode decision shapes everything — performance, freshness, and cost. Learn when to choose each.
What is a storage mode?
Think of three ways to read a book.
Import = downloading the entire book to your Kindle. Fast to read (it is on your device), but the version is frozen until you download again. DirectQuery = reading the book online, one page at a time. Always the latest version, but slower because every page request goes to the server. Direct Lake = the book is on a shelf right next to you — not downloaded into your device, but instantly accessible. Best of both worlds.
In Power BI, the storage mode determines where the semantic model reads its data from. This decision affects query speed, data freshness, and resource usage.
The three storage modes compared
| Feature | Import | DirectQuery | Direct Lake |
|---|---|---|---|
| Where data lives | In-memory (VertiPaq) | Source database | OneLake (Delta Parquet) → loaded into memory on demand |
| Query speed | Fastest — data is pre-loaded | Slowest — every query hits the source | Near-import — loaded from Parquet on demand |
| Data freshness | Stale until next refresh | Always current | Near real-time — reads latest Delta version |
| Refresh needed? | Yes — scheduled or on-demand | No — live connection | No traditional refresh — reads Delta log for changes |
| Data size limit | Limited by model memory (capacity-dependent) | Source database limits | OneLake storage (virtually unlimited) |
| DAX performance | Best — VertiPaq optimised for DAX | Depends on source query translation | Near-import — Analysis Services engine |
| Available in Fabric? | Yes | Yes | Yes — Fabric only (not Azure PBI) |
Direct Lake: Fabric’s game-changer
Direct Lake is unique to Microsoft Fabric and is the recommended storage mode for new semantic models.
How Direct Lake works
- Delta tables in a lakehouse or warehouse store the data as Parquet files
- When a query arrives, the Analysis Services engine reads the relevant Parquet columns directly from OneLake into memory
- Once loaded, queries run at Import-speed because the data is in the VertiPaq columnar store
- When the Delta table is updated, the engine detects the change and loads the new data on the next query
Direct Lake vs Import vs DirectQuery
| Scenario | Best Mode |
|---|---|
| Small dataset, infrequent updates | Import (simplest) |
| Large dataset in Fabric lakehouse/warehouse | Direct Lake (best performance/freshness) |
| Source outside Fabric (Azure SQL, on-prem) | DirectQuery or Import |
| Real-time dashboard (sub-second freshness) | DirectQuery (to Eventhouse or SQL) |
| Mixed: some Fabric data + some external | Composite model (Direct Lake + DirectQuery) |
Exam tip: Direct Lake fallback
When Direct Lake cannot load data (e.g., the Parquet files exceed memory, or the data requires unsupported types), it falls back to DirectQuery. The semantic model continues working but queries are slower.
You can configure fallback behavior:
- Automatic fallback (default) — seamless switch to DirectQuery when needed
- Disabled fallback — queries fail instead of falling back (use when you want to guarantee Import-speed performance)
The exam tests whether you understand when fallback occurs and how to configure it.
Composite models
A composite model mixes storage modes within the same semantic model. This is powerful when you need data from multiple sources with different performance characteristics.
Common patterns
| Pattern | Tables | Why |
|---|---|---|
| Direct Lake + Import | Large fact tables as Direct Lake, small reference tables as Import | Dimension tables are small enough to import; fact tables are too large |
| DirectQuery + Import | Live data as DirectQuery, historical data as Import | Current month from live source; previous months cached |
| Direct Lake + DirectQuery | Fabric data as Direct Lake, external data as DirectQuery | OneLake data at Direct Lake speed; external data via DirectQuery |
Scenario: James builds a composite model
James at Summit Consulting builds a semantic model for Client C that combines:
- Direct Lake: 500M rows of transaction data in a Fabric lakehouse (fast, no refresh needed)
- DirectQuery: Live CRM data from the client’s Salesforce instance (always current, cannot be imported)
- Import: A small reference table of exchange rates (updated weekly, only 200 rows)
The composite model gives James the best of all three: fast analytics on the big data, live CRM info, and a tiny cached reference table.
Anita at FreshCart has a 200-million-row fact table in a Fabric lakehouse and needs fast Power BI dashboards with near real-time data. Which storage mode should she choose?
James at Summit Consulting needs to combine Fabric lakehouse data with live Salesforce CRM data in a single semantic model. The CRM data cannot be imported due to licensing restrictions. Which approach should he use?
🎬 Video coming soon
Next up: Relationships & Advanced Modeling — bridge tables, many-to-many, role-playing dimensions, and relationship best practices.