Choose Import or DirectQuery from the workload
In this article (8 sections)
- Write requirements in measurable terms
- Compare the operating responsibilities
- Do not equate DirectQuery with instantaneous truth
- Evaluate security under the actual connection model
- Run a representative pilot
- Consider a mixed design only when it solves a clear need
- Make the decision reviewable
- Continue learning
Choose a Power BI storage approach from the required freshness, interaction latency, source capability, security model and operating constraints. Data size alone is insufficient. A mode that works for one report can perform poorly when many users open several visuals against the same source.
Import stores model data for analytical querying and needs a refresh strategy. DirectQuery sends queries to supported underlying sources as reports are used, subject to its caching and query behaviour. Neither choice removes the need to define data completeness and acceptable staleness.
Write requirements in measurable terms
Replace “real time” with a concrete requirement: for example, accepted source records should become visible within a specified number of minutes under a defined load. State whether users need second-by-second operations, hourly monitoring or a daily management report.
Define acceptable page and interaction latency, expected concurrent viewers, source-query budget and failure behaviour. Include the most demanding page, not only a single simple card.
The numbers should come from the business and an observed workload. Do not adopt an arbitrary latency threshold because it appears in a tutorial.
Compare the operating responsibilities
| Question | Import consideration | DirectQuery consideration |
|---|---|---|
| How current is the data? | Refresh schedule and successful load coverage | Source freshness plus query/cache behaviour |
| Where does interactive work run? | Primarily against the imported model | Often involves source queries and network paths |
| What must be provisioned? | Model and refresh resources | Source capacity, connectivity and query performance |
| What happens during source trouble? | Previously imported data may remain available but stale | Interactions can be affected by source availability |
Microsoft's DirectQuery guidance explains supported scenarios, limitations and alternatives. Check the current connector and capacity requirements for your environment before making a selection.
Do not equate DirectQuery with instantaneous truth
The source itself may update in batches. A query can return the latest committed source data while still missing events not yet ingested. Report caching, visual refresh and user interaction also affect what is displayed.
Track source-loaded-through time separately from query time. A report opened now can still represent yesterday's completed source batch. Define how the interface will communicate that state.
Likewise, frequent Import refresh does not guarantee freshness if every run succeeds against an incomplete upstream extract. Freshness is an end-to-end property.
Evaluate security under the actual connection model
Establish which identity queries the source and which restrictions the semantic model applies. Do not assume that source permissions automatically reproduce the desired per-user policy under every connection configuration.
Test representative consumers with allowed and forbidden records. Include any single-sign-on, gateway or embedding path actually used by the application. A mode decision that ignores identity can produce an operationally unsuitable design even when performance is acceptable.
Run a representative pilot
Use a controlled source and the same report definitions for each candidate configuration. Measure initial page load, common slicer changes, detailed tables and expected concurrency. Record source query volume and failures alongside user-facing latency.
Verify result equivalence with fixed source snapshots or carefully controlled observation times. Otherwise a fresher query can legitimately differ from an earlier imported snapshot, and the comparison may misclassify that as a calculation defect.
The tiny retail teaching fixture is suitable for checking measure logic, but it cannot establish production performance or source scalability. Use representative volume and distribution for the pilot.
Consider a mixed design only when it solves a clear need
Some workloads benefit from imported historical data plus a more current source-backed portion, aggregations or other supported composite designs. Those approaches add relationship, freshness and operational complexity.
Document which data is current under which rule and test measures across the boundary. A hybrid label does not guarantee that historical corrections, security or cross-source relationships behave as intended.
Make the decision reviewable
Save the requirements, candidate configurations, observed results, rejected constraints and maintenance owner. Revisit the choice when concurrency, source architecture or freshness requirements change.
Exercise: define two hypothetical workloads: a daily management report and an operational queue. For each, state the freshness and interaction requirements, then identify the measurements needed before choosing a storage mode. Do not select solely from the workload's name.
NeuraPath's Data Analytics with Generative AI course connects Power BI design with practical delivery decisions. A strong storage-mode comparison uses reproducible workload evidence and explicit operating responsibilities.
Continue learning
This article is part of the Power BI data models and reporting sequence. Use the neighbouring tasks when you need the prerequisite or the next application.
- Review the prerequisite or neighbouring task in Row-level security: test what each role can actually see.
- Continue with Power BI incremental refresh and historical corrections.
Pankit Kumar has 10 years in Data Science & AI, building and shipping production systems in regulated pharma and clinical environments. He is a freelance trainer at Boston Institute of Analytics, AnalytixLabs and Scaler, and has taught this material to thousands of working professionals.
This article is part of our Data Analytics with Generative AI programme — 3–4 months. The full analyst stack — Excel, SQL, Power BI and Python pipelines — then a generative-AI layer you can prove is right.
Explore Data Analytics with Generative AI