Power BI storage mode determines where query work happens, how fresh data can be, how much capacity is used, and which modeling features are available. For Microsoft PL-300, the practical decision is between loading data into the semantic model with Import, leaving query execution at the source with DirectQuery, or using Direct Lake against supported Microsoft Fabric data in OneLake. Microsoft DP-600 extends the same decision into larger Fabric architectures.

The platform comparison in Power BI and Microsoft Fabric explains the broader product boundary. Storage mode is narrower: it determines how a semantic model serves data. The right mode depends on source location, freshness, scale, performance, capacity, transformation requirements, and governance—not on which option sounds newest.

Import gives the semantic model its own in-memory copy

Import mode loads data into Power BI’s columnar in-memory engine. Queries are served from the semantic model rather than being sent to the source for every visual interaction, which usually produces strong interactive performance when the model is designed well.

The tradeoff is refresh. Incremental refresh can reduce processing for large imported models when only recent partitions change, but the model still needs enough capacity for the in-memory data and refresh operations. Monitor refresh duration, failures, and memory pressure as the dataset grows rather than assuming today’s schedule will remain viable. Imported data represents the last successful refresh, so the refresh schedule and duration determine freshness. Large models also consume capacity memory and require processing time. Import is often the best starting point when data volume and refresh requirements fit the platform. It also isolates report users from transient source-system load and outages after the refresh has completed. That can make analytical availability more predictable, but it means the organization must monitor whether the copied data is stale when refresh fails.

DirectQuery leaves detailed data at the source

DirectQuery keeps data in the external system and sends queries to that source as users interact with reports. This can support very large or frequently changing data when importing a copy is undesirable, but report performance becomes dependent on the source database, network, query folding, concurrency, and generated query efficiency.

Use DirectQuery when source-side freshness or scale justifies the tradeoff. Model authors should understand which Power Query steps fold to the source and which force inefficient intermediate processing. A seemingly simple transformation can turn into expensive source queries when folding breaks or when each visual generates repeated complex SQL. Optimize indexes, partitions, aggregations, source capacity, and model design. A slow source cannot be made fast by the Power BI visual layer, and many small visual queries can create more load than a single analytical SQL workload.

Direct Lake reads Fabric data from OneLake

Direct Lake is designed for supported Fabric data stored as Delta tables in OneLake. It is especially attractive when the organization already uses Fabric engineering or warehouse workloads and wants the semantic model to consume the same governed lake data without a separate import copy. That architectural alignment can simplify data movement, but capacity planning still matters. It provides an experience closer to Import performance without requiring a traditional data copy into the semantic model. Current Direct Lake capabilities depend on the source type and whether the model uses Direct Lake on OneLake or a supported SQL analytics endpoint path.

Direct Lake requires Fabric capacity and supported OneLake-resolvable data. The semantic model should be designed around Delta tables with suitable grain and business structure because Direct Lake does not remove the need for a clean model. OneLake shortcuts and supported source patterns can broaden the data reach, but their operational behavior still needs validation. It is not a general replacement for every connector. If the source is an external operational database or SaaS application that is not represented through supported Fabric tables, Import or DirectQuery may remain the appropriate choice.

Freshness is different in each mode

Import freshness depends on scheduled, on-demand, incremental, or other refresh behavior. DirectQuery asks the source at query time, although caching and report behavior can affect what users experience. Direct Lake reflects data in the lake without the classic full import-refresh cycle, but metadata and model state still need to remain consistent with the underlying tables.

Define what “real time” actually means to the business. Also define freshness tolerance separately from query latency. A user may accept data that is five minutes old but still expect each interaction to return in two seconds. Storage mode should satisfy both dimensions rather than optimizing one and failing the other. A dashboard updated every fifteen minutes may meet the requirement without the complexity of DirectQuery. Conversely, an operational monitoring use case may need source-level freshness that makes a daily Import model unacceptable.

Modeling features and transformations influence the decision

Import gives the broadest freedom for Power Query transformations and semantic-model features because data is materialized in the model. DirectQuery restricts some calculated-column, table, and DAX scenarios because expressions must often translate to the source. Direct Lake also has capability considerations tied to Fabric and source features.

Push heavy reusable transformations upstream when they belong in the data platform. In Fabric, Warehouse or Lakehouse transformations can produce reusable tables for several semantic models, which reduces duplicated Power Query logic and makes data quality ownership clearer. Keep report-specific calculations in the semantic layer when they are truly model logic rather than source preparation. A semantic model should not compensate for an unprepared source by repeating expensive transformations on every query. Star-schema design, clean dimensions, and stable business logic improve all three modes.

Composite models can mix storage strategies

A model does not always need one mode for every table. Composite models can mix Import and DirectQuery, and Dual storage can let certain tables behave efficiently in either path. Hybrid patterns can keep small dimensions in memory while large facts remain at the source.

Mixed storage increases reasoning complexity. Dual dimensions, aggregation tables, and DirectQuery facts can improve performance, but they make query paths less obvious to model authors. Document why each table has its storage mode and verify query behavior with Performance Analyzer rather than assuming the engine always chooses the expected path. Relationships, query routing, security, and performance can behave differently depending on which tables participate in a visual. Use composite design to solve a measured problem rather than as a default architecture.

Concurrency and source capacity matter most for DirectQuery

One fast DirectQuery test by a developer does not predict performance for hundreds of users. Test realistic concurrency, report pages, filters, and source workloads. A source database may be fast for one query but become the bottleneck when dozens of visuals from many users issue concurrent requests and compete with operational transactions. Each report page can generate multiple source queries, and interactive filtering can create bursts. Measure concurrency against realistic source capacity and review query plans from the generated workload.

Use the Optimize ribbon and query-reduction options when appropriate, simplify visuals, and avoid pages that trigger many expensive queries simultaneously. If the source must scale dramatically just to support report interactivity, Import or a Fabric-based architecture may be more economical.

Security and governance remain independent of storage mode

RLS, object permissions, sensitivity labels, workspace access, and source permissions still need deliberate design. Import mode creates a governed copy whose access is controlled by Power BI, while DirectQuery and Direct Lake may keep data closer to source systems. Understand which layer enforces security for every query path and test representative roles. DirectQuery can rely on source-side identity patterns in some architectures, while Import centralizes a copy of data in the semantic model. Direct Lake ties the semantic model closely to Fabric and OneLake governance.

Choose the mode only after understanding where sensitive data is stored and which identity is used to access it. Performance convenience should not create an unauthorized copy, bypass source policy, or expose lake data to users who should only see a filtered semantic model.

Choose with evidence and revisit as the workload changes

Start with the simplest mode that meets freshness and scale requirements, then validate with production-like data and user concurrency. Record the decision assumptions—data size, refresh frequency, capacity, source latency, and expected users—so the team knows when growth invalidates the original architecture and a different mode should be reconsidered. Import is often the performance baseline, DirectQuery is appropriate when source freshness or scale dominates, and Direct Lake is compelling when the data already lives in supported Fabric storage and capacity.

Revisit the choice as data volume, licensing, Fabric adoption, refresh windows, source performance, and user expectations change. Storage mode is an architectural decision with operational consequences; it should be measured and maintained rather than selected once from a feature table. Keep a short architecture record explaining why the mode was chosen, which assumptions matter, and what thresholds—data size, refresh duration, source concurrency, or Fabric adoption—would trigger a reassessment. Re-test after major source, capacity, model, or licensing changes.

Include source-system concurrency and governance in the storage-mode decision. DirectQuery can preserve source freshness but also sends interactive demand back to the source, where user concurrency, row-level security, and complex transformations may become bottlenecks. Import isolates report performance from source latency but introduces refresh windows. Direct Lake can reduce that tradeoff in Fabric. Direct Lake on SQL can fall back to DirectQuery when supported conditions prevent direct operation, whereas Direct Lake on OneLake has no DirectQuery fallback; model design and capacity still determine whether the experience remains interactive under real workloads.