When each table storage mode fits a semantic model, based on data size, latency, source security and capacity.
From Ultra Transcenders DP-600 by Tony Rough (coming December 2026)
Storage mode is a property of each table, not of the model as a whole, and it decides whether the engine answers a query from its in-memory VertiPaq cache, from Delta tables in OneLake or by sending a native query to the source. Learn’s guidance is to use Import by default and move to another mode only when latency, size, governance, security or architecture require it.
| Storage mode | Where the data lives | Refresh behaviour | Typical use |
|---|---|---|---|
| Import | Compressed snapshot in the model (VertiPaq) | Refresh the model or table to see new data | Default choice; richest features and fastest queries; any connector |
| DirectQuery | Stays in the source; each visual sends native queries | No data refresh; caches can still show earlier results until requeried | Very large or fast-changing data, source-enforced security (SSO), data that mustn’t be copied |
| Dual | Cached like Import, but can also act as DirectQuery | Cache refreshed like Import | Dimension tables queried together with DirectQuery fact tables from the same source |
| Direct Lake on OneLake | Delta tables in OneLake, loaded into memory on demand | “Refresh” (framing) copies only metadata; automatic updates by default | Large Fabric lakehouse or warehouse data; can combine several Fabric sources and Import tables |
| Direct Lake on SQL | Delta tables discovered through one SQL analytics endpoint | Framing, as above | Single Fabric source; falls back to DirectQuery for views, SQL granular access control or guardrails |
| DirectQuery on Power BI semantic models | A remote published semantic model | Queries run on the source model | Small changes or extensions to an existing shared model |
| Hybrid (a partitioned table) | Import partitions plus one DirectQuery partition | Incremental refresh manages partitions | Real-time latest data with imported history |
A live connection is different from all of these: a report connected live to a published semantic model has no local model at all (a “thin report”), and any measures created are report measures stored in the report. A model whose tables use more than one storage mode, or DirectQuery tables from more than one source, is a composite model (covered later in this chapter).
For most tables the storage mode is set when the table is added. A DirectQuery table can be switched to Import or Dual, but in Power BI Desktop it can’t then be set back to DirectQuery (Power BI web modelling and live editing in Desktop have version history that can reverse it). A Direct Lake on OneLake table can be converted to Import by using semantic link labs in a Fabric notebook. An entire Import model can’t simply be toggled to DirectQuery; instead you add a new DirectQuery connection, build a composite model or use hybrid tables.
When one DirectQuery table is switched to Import, Power BI Desktop offers to set related dimension tables to Dual. Its propagation logic calculates the minimum set of tables that must be Dual and only walks to the “one” side of one-to-many relationships. Queries that touch only Import or Dual tables are answered from the cache; a query that combines a Dual dimension with a DirectQuery fact from the same source is sent entirely to the source. Learn calls Dual a performance optimisation: an out-of-date cache can return values that differ from the source, and the engine doesn’t mask that.
Common trap: Setting a table to Import “to test it” and switching it back to DirectQuery afterwards - in Power BI Desktop a table changed from DirectQuery to Import or Dual can’t be set back to DirectQuery; only web modelling or live editing with version history can reverse the change.
Common trap: Choosing Direct Lake for a workspace on a Pro or Premium Per User licence - Direct Lake storage mode is licensed only on Fabric capacity SKUs, while Import and DirectQuery work with any Power BI or Fabric licence.
This note is one section of Ultra Transcenders DP-600: Implementing Analytics Solutions Using Microsoft Fabric, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · DP-600 terms in the glossary · All DP-600 study notes
How the two Direct Lake flavours differ in table discovery, permission checks, fallback and unsupported cases, and which one to choose.
What each Fabric workspace role can do across Power BI, data engineering, warehousing and real-time items.
Which items and settings a deployment copies or leaves alone, and how data source and parameter rules point each stage at its own data.
How data type, team skills, write needs and transactions decide between Fabric's lakehouse, warehouse, eventhouse and other stores.
What the Warehouse can do that a lakehouse's read-only SQL analytics endpoint can't, and when to use each.
The three many-to-many scenarios in a semantic model and the bridge-table or relationship design each one needs.
How data volume, transformation needs, skills and latency decide which Fabric tool should copy data into OneLake.