Power BI DirectQuery vs Import: How to Choose (and What PL-300 Asks)

One of the first modeling decisions a student makes on any new dataset is also one of the most consequential, and it happens before a single visual gets built: how should this table connect to Power BI? Import and DirectQuery aren't just two settings in a dropdown — they change how fast your reports feel, how fresh your data is, and even which DAX functions you're allowed to use. PL-300 tests the trade-off directly, usually as a scenario question rather than a definition, so it's worth understanding the mechanics rather than memorizing a rule of thumb.

What Import mode actually does

Import is the default, and it's what most PL-300 courses teach first. When you import a table, Power BI copies the data out of the source and loads it into VertiPaq — the in-memory, columnar storage engine built into the semantic model. Once loaded, the data lives inside the .pbix (or the published dataset) itself; the source system isn't touched again until you refresh.

That copy is what makes Import fast. VertiPaq compresses columnar data aggressively and every DAX calculation runs against data already sitting in memory, so even complex measures return in milliseconds on well-modeled data. The cost is staleness: what you see is only as current as your last refresh, and refreshes are scheduled (up to 8 times a day on Power BI Pro, more with Premium capacity and incremental refresh policies). Import also has no restrictions on which DAX functions you can use — every time intelligence function, every iterator, everything works, because the engine is operating on data it fully owns.

What DirectQuery actually does

DirectQuery leaves the data where it is. No copy is made — every time a visual needs data, Power BI translates that request into a native query (SQL, for most relational sources) and sends it to the source system live. The report always reflects the current state of the source, which is the entire appeal: no refresh schedule, no lag.

That live round-trip is also the cost. Query performance now depends entirely on the source: an unindexed table or an underpowered database will make every visual feel sluggish, because Power BI is waiting on someone else's query engine, not its own. DirectQuery also restricts what you can do in the model — some DAX functions either aren't supported or behave differently (time intelligence functions in particular have restrictions depending on the source), Power Query transformations are limited to steps that "fold" back into the native query language, and by default a single visual is capped at returning one million rows. None of these are arbitrary limitations; they exist because DirectQuery has to translate everything into a query the source can actually execute.

Query folding is the hidden mechanic

DirectQuery's usability lives or dies on query folding — Power Query's ability to push your M transformations down into the native query sent to the source, instead of pulling raw data back and transforming it locally (which DirectQuery mostly can't do anyway). A filter, a group-by, a join: these fold cleanly into SQL on most relational sources. A custom M function or a step that requires row-by-row logic Power Query can't translate often breaks folding, and in DirectQuery that's not just a performance hit — some non-folding steps simply aren't allowed. If you're building a DirectQuery model, check the "View Native Query" option in the Power Query Editor as you build each step; the moment it disappears, that step broke folding.

Composite models and dual storage mode

You don't have to pick one mode for an entire semantic model. A composite model mixes storage modes table by table — a large, frequently changing fact table can stay in DirectQuery while your smaller, slow-changing dimension tables (Date, Product, Region) are imported for speed. This is the practical middle ground most real deployments land on: you get near-real-time facts without paying DirectQuery's latency tax on every lookup against a dimension table.

There's a third setting worth knowing for the exam: Dual storage mode. A dual table can behave as either Import or DirectQuery depending on which fact table it's being queried alongside — Power BI picks whichever avoids an unnecessary cross-source query. Dimension tables in a composite model are commonly set to Dual rather than pure Import, specifically to avoid the "relationships between DirectQuery and Import tables may cause ambiguous results" warning that composite models can otherwise throw.

What PL-300 actually asks

The exam rarely asks "define DirectQuery." It gives you a scenario and asks which storage mode — or which change to an existing model — fits the stated requirement:

• A scenario stresses that data must never be more than a few minutes old, or that a business user needs to see transactions "as they happen" — that's DirectQuery, or at minimum a DirectQuery fact table in a composite model.
• A scenario stresses report performance complaints, heavy DAX usage, or a source system that can't handle direct report traffic — that points to Import, possibly with incremental refresh if the data volume is large.
• A scenario describes a large fact table that changes constantly alongside dimension tables that barely change, and asks for the best-performing design — that's the composite-model answer, with the dimensions set to Dual.
• A question flags an error about ambiguous relationships between storage modes — that's testing whether you know Dual mode is the fix, not a random troubleshooting step.

How to decide on a real project

Ask two questions before you touch the storage mode dropdown. First: does this report genuinely need data fresher than a scheduled refresh can provide, or does "fresh enough" actually mean "refreshed this morning"? Most business reporting — sales dashboards, HR metrics, monthly finance packs — tolerates a refresh schedule perfectly well, and Import's speed and full DAX support make it the better default. Second, if you do need DirectQuery: is the source tuned to handle it — proper indexing, a data warehouse rather than a transactional OLTP database, realistic concurrent user counts? DirectQuery against an untuned source doesn't just feel slow, it can create load problems for the system everyone else depends on.

My rule of thumb after years of building both: default to Import, and only reach for DirectQuery (or a composite model) when you can name the specific requirement — data freshness or data volume that exceeds what Import can practically hold — that Import can't satisfy. If you can't name that requirement, you probably don't need DirectQuery yet.