When you start a report in Power BI, one of the first decisions — often made without a second thought — is how the model will get its data: bring a copy inside the file (Import) or query the source every time someone opens a visual (DirectQuery). It looks like a technical detail, but it shapes performance, data freshness, cost, and even which DAX functions you can use.
The wrong choice shows up quickly: reports that take seconds to react to every click, refreshes that fail in the middle of the night, or numbers that are never fresh enough for the people consuming them. The good news is that the decision follows reasonably clear rules, as long as you understand what each mode does under the hood.
In this article we compare the two storage modes without romanticism: how they work, where each one shines, what limits they impose, and how to combine them when neither one, on its own, is enough. By the end, you'll have a simple criterion to decide case by case.
What changes between Import and DirectQuery
The essential difference is where the data lives at the moment the report is queried. In Import mode, Power BI reads the source, compresses the data, and stores it inside the model. From then on, every calculation runs against that local copy. In DirectQuery, there is no copy: each visual generates a query that is sent to the source (a SQL database, a data warehouse, and so on) and the result comes back in real time.
That distinction explains almost everything else. Import is fast because it doesn't depend on the source for each interaction, but it holds a snapshot of the data that only changes when a refresh runs. DirectQuery is always in sync with the source, but it pays for that freshness with latency and with a total dependency on the performance of the origin system.
Import: data in memory with the VertiPaq engine
In Import mode, the data is loaded into VertiPaq, Power BI's in-memory columnar engine. VertiPaq compresses columns very efficiently — it's common to see tables of tens of millions of rows take up a fraction of their original size — and answers analytical queries at a speed that's hard to match.
That's why Import is the default choice for most reports. You get access to the full DAX language, fast aggregations, and fluid interaction with slicers and filters. The price is that the model has to fit in memory and that the data only reflects the source up to the last refresh. Model size limits depend on your license and capacity — what's comfortable in Power BI Premium may not fit in a more modest plan.
DirectQuery: querying the source in real time
In DirectQuery, the model stores only the metadata — the structure of the tables and the relationships — and not the data itself. Every time a user interacts with a visual, Power BI translates the operation into a query against the source. This has an obvious advantage: the numbers are always as up to date as the underlying database.
It's the right approach when data changes by the minute (stock or operations, for example), when the volume is so large that importing it wouldn't make sense, or when there are governance requirements that demand the data never leaves the source. In exchange, you depend on how fast that source is: if the database is poorly indexed or overloaded, the report inherits that slowness.
Performance: why Import almost always wins
All else being equal, Import is faster. Queries run against VertiPaq, in memory, with no network round trips and without competing with the source's transactional load. In DirectQuery, each interaction is a round trip to the database, and several visuals on the same page can fire several queries at once.
This doesn't mean DirectQuery is slow by nature. With a well-optimized source — proper indexes, aggregation tables, a data warehouse designed for analytical reads — it can perform perfectly acceptably. But it demands engineering work on the source side that Import largely spares you.
Refresh and data freshness
Here the roles reverse. In Import, freshness depends on the refresh frequency you configure — hourly, a few times a day, or the most your license allows. Between refreshes, the report shows the last snapshot. For many management decisions, that's more than enough.
In DirectQuery, the data is always current by construction, because it's read from the source at that moment. If your question is «how many units do I have in the warehouse right now?», DirectQuery answers with the truth of the instant; Import answers with the truth of the last refresh. Choosing between them is, at heart, deciding how much staleness the business tolerates.
Limits and restrictions of each mode
DirectQuery comes with restrictions worth knowing before you decide. Not all DAX functions are available, some Power Query transformations aren't supported, and there is a practical limit on how much each query can return. By default, a DirectQuery query fails if an intermediate result exceeds around one million rows — a brake designed to avoid queries that would consume excessive memory and time (in Premium capacities this limit can be raised).
Import has a different kind of limit: the whole model has to fit within your capacity's size limits. Very large models force strategies such as incremental refresh, aggregations, or reducing detail. These are different problems, but both shape the decision.
Composite models and Dual mode: the best of both
Fortunately, you don't have to choose one mode for the entire model. Composite models let some tables be in Import and others in DirectQuery within the same report. Dual mode goes further: a table can behave as Import or as DirectQuery depending on the query, which is especially useful for shared dimension tables.
The most common pattern combines a huge fact table in DirectQuery with small dimensions in Import (or Dual), often with aggregation tables on top to answer the most frequent questions instantly. It's a way to have freshness where you need it and speed where you can get it.
Mini case study: slow reports at a retail company
Imagine a retail company with around 200 stores that built a sales dashboard in DirectQuery directly on top of the transactional database. At the start of the month, when everyone opened the report at the same time, each click took six to eight seconds and the operational database felt the weight of analytical queries competing with sales.
The team reconfigured the model: they moved the historical sales data to Import, refreshed hourly, and kept only the real-time stock table in DirectQuery, through a composite model. The response time of the historical visuals dropped to under a second, the load on the operational database vanished, and the stock indicator kept showing the value of the moment. Nothing magical — just the right mode for each table.
Cost, maintenance and the human factor
There's a cost that rarely makes it into the calculation: maintenance. A well-designed Import model tends to be more predictable — it refreshes, it works, and most problems are solved inside Power BI. A DirectQuery model spreads the responsibility: report performance now depends on whoever manages the database, on the indexes, on concurrent load, and on the network. When something goes wrong, the investigation involves more people and more layers.
This isn't an argument against DirectQuery — it's a reminder that choosing the storage mode is also an organizational choice. If you don't have anyone to tune the source, a poorly supported DirectQuery quickly turns into user complaints. If, on the other hand, you have a solid data team and a well-kept warehouse, DirectQuery's maintenance cost stops being an obstacle.
How to choose: a quick guide
As a general rule, start with Import and only move away from it when there's a concrete reason. These are the signs that usually justify DirectQuery (fully or partially):
- Freshness by the minute: the business needs to see data practically in real time, and an hourly snapshot isn't enough.
- Unmanageable volume: the source has so much data that importing it isn't viable within your capacity's limits.
- Governance requirements: by policy or regulation, the data can't be copied outside the origin system.
- Source already optimized for reads: you have a fast data warehouse, with aggregations and indexes, ready to handle analytical queries.
If none of these apply, Import will almost certainly give you a better experience with less effort. And when a single mode doesn't solve it, remember that the composite model exists precisely for those in-between cases.
In practice
Import and DirectQuery aren't rivals to be eliminated, but tools for different contexts. Import delivers speed and the full DAX language at the cost of working with a snapshot of the data; DirectQuery delivers permanent freshness at the cost of latency and restrictions. Maturity lies in knowing when each one fits — and in using composite models when the right answer is «it depends on the table».
Before you decide, ask three simple questions: how often the data changes, what volume we're talking about, and how fast the source is. The answers almost always point to the right mode. Choose with intent, not out of habit, and your report will thank you — with every click.
