Storage Modes

Import, DirectQuery, and Direct Lake solve the same design problem in different ways: where should a Power BI semantic model obtain table data when a report needs an answer? The choice sets the balance among query speed, data freshness, modeling flexibility, source workload, and data-residency requirements.

Start with the query path

A storage mode determines how a model table obtains data for an analytic query. Begin with that path; the benefits and limitations follow from it.

Storage mode is a property of a model table, not a choice made separately by each report visual. The three-way decision depends on where the data resides and how it should be queried.

Imagine a report visual that groups sales by month. The visual sends an analytic query, but the route differs:

• With Import, the model answers from its stored copy.
• With DirectQuery, Power BI passes the query to the operational source and returns its result.
• With Direct Lake, a Fabric semantic model reads the relevant OneLake Delta data directly.

That makes the first design question concrete: Can the data be copied into a model, must it remain at a supported source, or is it already lake data in OneLake? Only then should you weigh refresh latency, interactive performance, model size, and source capacity.

Import optimizes a cached copy for analysis

An Import table answers queries from data stored, or cached, in the Power BI model. The cache is optimized for analytic work such as filtering, grouping, and summarizing, and the model is stored in memory. That is why Import usually delivers the fastest interactive query performance.

Import also provides the broadest design flexibility. It supports Power BI data source types including databases, files, feeds, web pages, and dataflows. An import model can use DAX and Power Query functionality and can include calculated tables. Power BI Desktop therefore uses Import by default when you select Get data.

Use this mode when a local copy is acceptable and the priority is strong interactive performance with extensive modeling options.

The tradeoff is freshness. Imported data must be refreshed periodically, either on demand or by a schedule after publication. Imported data is current only through the last successful refresh. A source change made after that refresh is not in the cached model yet.

The copy must also remain manageable. Reduce unnecessary data before loading it so model size and refresh duration stay under control. Typical reductions include removing unneeded rows or columns, summarizing a fact table to a higher grain, choosing efficient data types, and disabling load for queries that do not need to become model tables.

For a manageable source, an acceptable refresh schedule, broad modeling flexibility, and fast interactive queries, choose Import into a cached Power BI model.

DirectQuery trades the cache for source access

A DirectQuery table does not cache a complete copy of its data in the Power BI model. When a report query runs, a DirectQuery table obtains data from the underlying source through a pass-through query. Because the table does not require a data refresh, this path can return near-real-time results from rapidly changing data.

DirectQuery is a strong candidate when importing an entire large data store would be impractical, or when organizational policy prevents data from leaving an on-premises source. Large, fast-changing source data that should remain at the source most directly favors DirectQuery over Import.

The source and connector must support DirectQuery. The absence of an imported copy does not remove the need for a Power BI semantic model; it changes where the table data is retrieved.

The tradeoff moves to the source system. Every report interaction can create source work, so analytic queries may be slow when the source lacks suitable optimization or sufficient resources. They can also compete with other source workloads.

Design DirectQuery with the database owner. The source may need indexes, materialized views, and capacity for the expected analytic workload. The source must be able to sustain interactive queries; otherwise, near-real-time access can produce a poor report experience.

Not every data source supports DirectQuery. It is commonly available for major relational databases, plus supported Power BI semantic models and Azure Analysis Services models. A connector that only supports Import cannot be made into DirectQuery merely by avoiding refresh.

DirectQuery also constrains data preparation. Power Query transformations in a DirectQuery model must translate into native queries understood by the source. If a transformation cannot be expressed for source execution, it cannot remain part of that DirectQuery path. For example, pivot and unpivot are not available transformations in this model framework.

This restriction is part of the same design logic: DirectQuery depends on the source executing the work. Select it only when volume, velocity, near-real-time needs, or data-sovereignty rules outweigh Import's flexibility—and when a supported, well-resourced source can serve the report workload.

For a large, rapidly changing on-premises source whose policy forbids copying, choose DirectQuery to that supported source.

Direct Lake uses the lake without either detour

Direct Lake is for Microsoft Fabric semantic models over lake data. Direct Lake reads Delta tables directly from OneLake for a Microsoft Fabric semantic model. It does not first import those tables into model memory, and it does not send each report query on an external DirectQuery round trip.

That distinction matters. Import introduces a copied-data and refresh workflow. DirectQuery sends work to an external source. Direct Lake instead uses the lake-native Delta tables already held in OneLake.

It is therefore not a generic label for any direct connection. The data location and format are part of the requirement: the analytical data must be available as Delta tables in OneLake.

Direct Lake avoids a separate import and an external DirectQuery round trip when it reads OneLake Delta tables. Avoiding both data-import overhead and external query round trips makes it fast for many scenarios.

Direct Lake still uses a semantic model to serve reports. It avoids the two data-access detours; it does not avoid the semantic model, the Delta tables, OneLake, or the report visual itself.

Choose from requirements, not habit

Start with Import whenever the cached copy, model size, and refresh behavior satisfy the requirements. It offers extensive modeling options and fast interactive performance. Reduce the data before loading it so that this preferred path remains practical.

Move to DirectQuery when the source holds large or fast-changing data, users need near-real-time results, or policy prevents importing a copy. Verify that the connector is supported, transformations can translate to native queries, and the source can sustain interactive report traffic.

Select Direct Lake when a Fabric semantic model must read Delta tables from OneLake directly, without a separate imported copy or an external DirectQuery round trip. Direct Lake is a location-and-format choice as much as a freshness choice.

Use the scenario's non-negotiable requirement to decide:

Do not choose DirectQuery merely because it sounds more current, or Direct Lake merely because the project uses Fabric. Match the actual data residence, query path, and operational constraints.

Key takeaways

• Import caches table data in the model. It supports broad sources, DAX, Power Query, and calculated tables, and favors fast interactive queries—but the cache requires refresh and is only as current as the last successful one.
• DirectQuery leaves table data at a supported source and passes report queries to it. It suits large, rapidly changing, or non-copyable data, but source performance, source workload, connector support, and native-query translation become report concerns.
• Direct Lake reads OneLake Delta tables directly for a Fabric semantic model. It avoids a separate import and an external DirectQuery round trip.

The practical default is Import when its copy, size, and refresh latency are acceptable. Change modes only when data residence, data velocity, freshness, or policy provides a stronger requirement.