Choosing a Power BI semantic-model storage mode is an architecture decision, not a tuning checkbox. Import, DirectQuery, and Direct Lake determine where query work happens, how fresh data can be, how much data is copied into the model, which security patterns are available, and what users experience when reports become busy. In Microsoft Fabric, Direct Lake adds a third option that can combine in-memory analytical performance with OneLake data without a conventional import refresh.
The current DP-600 scope specifically requires analytics engineers to choose storage modes, design composite models, configure Direct Lake, understand fallback and refresh behavior, and choose between Direct Lake on OneLake and Direct Lake on SQL analytics endpoints. Those topics matter because “fastest” is not a universal answer. The right mode depends on source location, data volume, freshness, security, capacity, and model design.
A useful way to compare the modes is to ask where the semantic model gets its columns when a user runs a query. Import loads data into the model ahead of time. DirectQuery asks the source at query time. Direct Lake reads Delta data from OneLake and pages required columns into memory as needed. Each path has different trade-offs.
Import mode favors predictable in-memory performance
Import mode copies data into the semantic model and stores it in the highly compressed VertiPaq engine. Report queries are answered from that model rather than repeatedly querying the original source. For many business-intelligence workloads, this produces consistent interactive performance because transformations and source latency are removed from the user’s query path.
The trade-off is freshness and duplication. Imported data represents the state captured at the most recent successful refresh. Large models require time and capacity to process, and the organization now maintains another analytical copy in addition to the source. Incremental refresh and partitioning can reduce the amount processed, but refresh design remains part of operations.
Import is still attractive when the model fits comfortably in capacity, users need high query concurrency, and minute-by-minute freshness is unnecessary. It also provides a mature feature surface for semantic modeling. The broad skills described in DP-600 semantic-model design remain essential because storage mode cannot compensate for poor relationships, inefficient measures, or unnecessary columns.
Refresh architecture should be sized from data-change patterns rather than total table size alone. A large historical fact table with a small daily change can work well with incremental refresh, while a smaller table that must be fully recomputed may create more processing pressure. Monitor refresh duration and memory alongside report-query performance.
Import also creates a useful decoupling from source outages. Once the model is refreshed, reports can continue answering queries even if the operational source becomes temporarily unavailable. The downside is that the model cannot show changes made after the last successful refresh, so freshness objectives should be explicit to users and operators.
DirectQuery keeps data at the source but puts the source in the query path
DirectQuery does not import the full table into the semantic model. When a report interaction requires data, Power BI generates queries that are sent to the underlying source. That can provide fresher results and avoid storing a large duplicate model, but user experience now depends heavily on source performance, network latency, query folding, concurrency, and the efficiency of generated queries.
This mode can be appropriate when data must remain in a governed source, when volumes are too large for practical import, or when freshness requirements exceed the acceptable refresh interval. It can also be required by specific architecture or security constraints. The cost is that an analytical report can become a live workload on the source system.
Source design matters greatly. A relational engine with appropriate indexes, partitions, materialized aggregates, and workload management can serve DirectQuery effectively. A poorly tuned source can make even simple visuals feel slow. Report authors must also avoid pages that generate many expensive queries at once.
Concurrency is often the deciding factor. A DirectQuery report that feels fast for one developer may perform poorly when hundreds of users generate simultaneous queries against the same source. Load-test representative report pages and include peak business periods, not only isolated query benchmarks.
Caching can improve experience, but it changes how “live” the data really is and can mask source problems during testing. Document which layers cache results and how invalidation works so support teams can explain why two users may temporarily observe different states.
Direct Lake reads Fabric Delta data without a conventional import
Direct Lake is designed for semantic models over Delta tables in OneLake. Instead of importing the complete dataset through a scheduled refresh, the model can load needed columns from the underlying Parquet files into memory on demand. This reduces the traditional separation between the data lake and the semantic engine while preserving fast in-memory execution for supported queries.
Direct Lake does not mean that every query scans storage directly. The engine uses framing metadata and column loading so commonly used data can be served efficiently. Data changes in OneLake can become visible without the same full data-copy process associated with Import, although the model still has refresh or framing behavior that needs to be understood operationally.
The relationship between Microsoft Fabric and Power BI is especially important here. Direct Lake works because the semantic model is tightly integrated with the OneLake storage layer rather than treating Fabric as just another remote database.
Direct Lake on OneLake and Direct Lake on SQL are not identical
Current Fabric architecture distinguishes Direct Lake on OneLake from Direct Lake on SQL analytics endpoints. Direct Lake on OneLake can work with Delta tables across supported Fabric data sources and does not use the SQL analytics endpoint for normal query execution. Microsoft positions it as the recommended Direct Lake option for new semantic models.
Direct Lake on SQL uses a single Fabric data source and the SQL analytics endpoint for discovery and permission checks. Under certain conditions, a table can fall back to DirectQuery through that endpoint. SQL views, SQL-based row-level or object-level security, dynamic data masking, or capacity guardrail conditions can influence whether the engine remains in Direct Lake mode.
This distinction changes architecture decisions. Teams should know whether a security or modeling feature they plan to use is compatible with the intended Direct Lake path. Assuming that all Direct Lake models behave the same can produce unexpected performance when a model silently begins using DirectQuery fallback.
This distinction changes troubleshooting. With Direct Lake on SQL, a query can fall back to DirectQuery when a model depends on SQL endpoint capabilities that Direct Lake cannot serve in-memory under the configured behavior. The user may therefore experience source-query latency even though the model is labeled Direct Lake. With Direct Lake on OneLake, the model reads eligible OneLake data without that DirectQuery fallback path. Architecture reviews should identify which Direct Lake variant is in use and verify it from model configuration rather than assuming all Direct Lake models behave the same.
Freshness has a different meaning in each mode
Import freshness is refresh-driven. A business process may update the source continuously while reports remain on the last imported snapshot until the next refresh completes. Incremental refresh can make frequent processing more practical, but the semantic model is still refreshed as a managed data-copy operation.
DirectQuery asks the source during report queries, so it can expose current source state subject to caching and the source’s transaction behavior. That makes it useful for operationally fresh reporting, but it also means users can observe changing results and place repeated demand on the serving system.
Direct Lake separates data refresh from traditional import semantics. Because the underlying Delta tables reside in OneLake, the model can pick up changed storage through framing and automatic update behavior. Architects should still define what “fresh enough” means, how upstream tables are committed, and how users are protected from seeing partially prepared business states.
Freshness should be expressed as a business contract. For Import, define how long data may remain unchanged between refreshes and what happens when a refresh fails. For DirectQuery, define acceptable source latency and whether source-side replicas or caches can lag. For Direct Lake, define when new Delta data becomes visible to the semantic model and how metadata changes are handled. A dashboard that says “near real time” without those mechanics is not an architecture requirement; it is an aspiration.
Security requirements can determine the viable storage mode
Semantic-model row-level security and source-level security are different layers. With Import, the model contains imported data and Power BI security is normally the primary query-time control. With DirectQuery, the source may participate directly in authorization depending on connection and identity design. Direct Lake adds OneLake and SQL-endpoint considerations that vary by implementation option.
Direct Lake on SQL can fall back when the source uses certain SQL-based security features. That preserves functionality in some designs but can change performance substantially. Direct Lake on OneLake avoids SQL fallback, but architects need to understand OneLake security behavior and semantic-model permissions instead of assuming that a SQL security configuration carries over automatically.
The key is to design security and storage mode together. Do not choose Direct Lake for speed and then discover that a required source-security pattern forces a different execution path. Likewise, do not duplicate sensitive data into an imported model without considering the governance and access implications.
Capacity and data layout shape Direct Lake performance
Direct Lake relies on efficient Delta and Parquet layout. Excessive files, fragmented row groups, very wide tables, or data volumes beyond capacity guardrails can increase paging and prevent the model from operating as intended. The storage layer is part of semantic-model performance even though report authors may never interact with files directly.
Optimize upstream tables for analytical access. Remove unnecessary columns, choose sensible partitioning, compact small files where appropriate, and avoid forcing the semantic model to load data it cannot use. A star-schema design can reduce both model complexity and the amount of data needed for common queries.
Measure cold and warm behavior separately. The first query that needs a Direct Lake column may incur loading work that later queries avoid because the column is resident in memory. A benchmark based only on a warmed model can understate the experience after capacity pressure, model updates, or less frequently used report paths.
Capacity sizing should consider more than total model data. Concurrent users, memory pressure from other Fabric workloads, file layout, row groups, and frequently accessed columns all influence paging behavior. Direct Lake reduces traditional import processing but does not eliminate capacity engineering.
This is where Fabric analytics and data engineering overlap. The perspective in data storage and processing for Azure data engineers is useful because semantic performance ultimately depends on how data was prepared, not only on DAX and report design.
Composite models can combine modes when requirements differ
Not every table needs the same storage behavior. A semantic model might keep a small reference table in Import while large fact data uses Direct Lake, or combine DirectQuery sources with imported dimensions where supported. Composite models let architects tailor storage to data characteristics, but they also introduce relationship and query-planning complexity.
Use mixed modes intentionally. If a report joins a fast in-memory table to a slow DirectQuery source on every interaction, the slowest component may dominate the experience. Cross-source relationships and calculations can produce different query patterns from a single-mode model. Test representative report pages rather than assuming each table’s individual performance will carry through to the composite.
Document why each table uses its mode. Storage mode should be an architecture property that future maintainers can understand, not a collection of historical defaults left in the model.
Choose the mode from workload requirements, then prove it with tests
Import is usually strong when predictable interactive performance matters, data fits within practical model and refresh limits, and scheduled freshness is acceptable. DirectQuery fits scenarios where the source must remain authoritative at query time or data cannot be imported conveniently, provided the source can handle analytical concurrency. Direct Lake is compelling when data already lives in Fabric Delta tables and teams want tight OneLake integration without traditional import processing.
Run workload tests with realistic data volume, report complexity, user concurrency, security, and refresh patterns. Measure visual latency, source load, model memory, capacity consumption, and behavior after data changes. For Direct Lake on SQL, test whether planned features cause fallback; for Direct Lake on OneLake, verify that the data layout remains within practical limits.
For analytics engineers in the Microsoft ecosystem, the best storage mode is the one that aligns performance, freshness, security, and operational cost for the real workload. PL-300 practitioners may encounter the choices at the reporting layer, while DP-600 extends them into enterprise-scale semantic architecture. Direct Lake adds a powerful Fabric-native option, but it works best when teams understand precisely how it differs from both Import and DirectQuery.
Benchmark with representative semantic queries, concurrency, row-level security patterns, and data volumes rather than with one desktop author’s sample. Measure warm and cold behavior, capacity consumption, source pressure, refresh duration where applicable, and p95/p99 user latency. Include failure tests as well: unavailable SQL endpoints, delayed refreshes, capacity pressure, and schema changes can reveal operational differences that a happy-path performance test misses.