Power BI import vs DirectQuery: speed or freshness?
Power BI import vs DirectQuery is the first big design choice in any semantic model. Import copies data into a compressed, in-memory store, so visuals respond quickly. DirectQuery leaves data in the source and sends a query each time a reader interacts. One mode favors speed, while the other favors freshness. Most models do best on import, but there are sound reasons to choose otherwise.
- Trade-offs in plain words
- Mode-by-mode table
- Decide table by table
Last updated
Power BI import vs DirectQuery: how does each mode work?
With import, a refresh loads the source rows into the model. The engine compresses them column by column and holds them in memory. After that, every visual reads from the local copy, so the source system is not involved at all.
With DirectQuery, the model stores only the structure. When a reader opens a page, each visual turns into a query against the database. The answer comes back, and then the visual draws.
So the trade is clear. Import gives fast answers from data as of the last refresh. DirectQuery gives current data at whatever speed the source can manage.
What are the trade-offs between the modes?
The summary below follows Microsoft's general guidance on storage modes.
| Area | Import | DirectQuery |
|---|---|---|
| Where data sits | Inside the semantic model | In the source database |
| Visual speed | Usually fast | Depends on the source |
| Freshness | As of the last refresh | Current at query time |
| Size limits | Bound by license and capacity | Bound mainly by the source |
| Load on the source | Only during refresh | With every interaction |
| Modeling and DAX | Full feature set | Some limits apply |
| Upkeep | Refresh schedule to watch | Source tuning to maintain |
When is Power BI import mode the right default?
Import suits most business reporting. Sales, finance and operations figures rarely need to be current to the minute. A refresh a few times a day keeps them useful, and readers enjoy quick pages.
It also gives authors the whole toolbox. Every Power Query transformation and every DAX function works. Because the data sits in the model, calculations over time run without special care.
Size worries often fade with good design. For example, dropping unused columns and keeping only needed history shrinks a model sharply. Incremental refresh then reloads only recent periods. Therefore import is the sensible first try for most models. When an imported model still feels slow, see Power BI performance tuning.
When does DirectQuery make more sense?
The first reason is freshness. A dispatch screen or a stock position may need data that is seconds old. Since a refresh cannot run that often, a live query is the answer.
The second reason is scale. Some fact tables are too large to copy, even after trimming. When a fast warehouse already holds them, querying in place avoids the copy.
The third reason is policy. Some companies require that data never leave the source system, or that database security applies to each reader. However, this mode moves the performance burden to the database. So the source needs indexes, a clean design and enough capacity for many readers at once.
Power BI import vs DirectQuery: how should you decide?
Decide per table, not per model, and follow these steps.
State the freshness need
First ask the business how old the data may be. An honest answer is often hours, not seconds.
Measure the volume
Then estimate the model size after removing unneeded columns and rows. Many large tables fit once they are lean.
Test the source
If a live query looks necessary, run typical report queries against the database and time them under load.
Consider a mix
Finally, look at composite models. Small dimension tables can load into memory while one huge fact table stays live.
Power BI import vs DirectQuery: common questions
Can one Power BI model use import and DirectQuery together?
Yes. A composite model lets each table have its own storage mode. A common pattern imports dimensions and summary tables while the detailed fact table stays live. Aggregations can then answer most visuals from memory. So readers get speed for everyday questions and fresh detail when they drill down.
Is a live connection the same as DirectQuery?
No, although the names sound alike. A live connection links a report to an existing semantic model or an Analysis Services model, and the report adds no tables of its own. DirectQuery links a model to a database and translates visuals into source queries. The two differ in what authors can change.
What is Direct Lake, and where does it fit?
Direct Lake is a newer storage mode in Microsoft Fabric. It reads table files in OneLake straight into memory, without a scheduled copy. In other words, it aims for import-like speed with fresher data. It needs a Fabric capacity and data stored in the lake, so it suits teams already on that platform.
Why is our Power BI DirectQuery report slow?
Usually the source is the cause. Each visual sends at least one query, and a busy page sends many. Missing indexes, complex views and wide tables all add delay. We trace the queries, simplify the model and tune the database. Sometimes the honest fix is to switch suitable tables to import.
Can you review our model and recommend a mode?
Yes. We look at data volumes, refresh history and what readers really need, then suggest a mode for each table. It begins with a free 30-minute assessment. Power BI Agency is a division of Sataware Technologies and is independent of Microsoft. The work happens remotely inside your own tenant.
Related pages
Let's build your first dashboard together.
Tell us what you report on today. A consultant replies within 2 hours with next steps.
Trusted partners
Microsoft Solutions Partner · AWS Partner
Cloud & AI Platforms
Azure SQL, Microsoft Fabric and the data pipelines behind your reports.
AI Business Solutions
Power BI reporting on your Dynamics 365, Business Central and Power Platform data.
Security
Row-level security and Entra ID sign-in on every report and workspace.
Amazon Web Services
Power BI on your AWS data, with connectors for Redshift, Athena and S3.