Import vs DirectQuery vs Direct Lake: Choosing the Right Power BI Storage Mode

Three storage modes, three trade-offs between freshness, speed and scale.

Every Power BI model makes one decision before any visual is drawn: where the data lives when a user asks a question. Inside the model? Back in the source? Or read directly from a lake?

That choice - Import, DirectQuery or Direct Lake - sets the ceiling on speed, the floor on freshness and the shape of your costs. Most struggling deployments did not choose badly so much as never consciously choose at all: they inherited a default and discovered its limits in production.

This guide explains how each mode actually works, the trade-off triangle between them, and a selection matrix for the scenarios mid-market businesses actually run.

Key Takeaways

• Storage mode is a trade-off triangle - freshness, query speed and data scale, and every mode privileges two at the expense of the third.

• Import remains the right default for most reporting; DirectQuery earns its keep only where genuine real-time need exists.

• Direct Lake changes the equation on Fabric - near-Import speed without refresh windows, for estates that have outgrown both.

How Does Each Storage Mode Actually Work?

Import copies data into a compressed in-memory engine inside the model; DirectQuery leaves data at the source and translates every visual into a live query against it; Direct Lake reads Delta tables straight from OneLake without either copying into a model or querying a database. Each is a different answer to the same question: who does the work when a user clicks?

The mechanics matter because they predict the failure modes. Import's VertiPaq engine is extraordinarily fast at scanning compressed columns - but only over data it loaded at the last refresh. DirectQuery is only ever as fast as the source database under concurrent load. Direct Lake gets Import-class scan speed because the lake's Delta format is already columnar - the model becomes a smart reader rather than a second copy.

What Is the Trade-Off Triangle You Cannot Escape?

Freshness, speed and scale - pick two. Import gives speed and scale but data is only as fresh as the last refresh. DirectQuery gives freshness and scale but every click pays a database round-trip. Pre-Fabric, genuinely wanting all three meant compromise architectures; Direct Lake is Microsoft's attempt to collapse the triangle.

The symptoms of choosing the wrong corner are recognisable:

• Import chosen, freshness needed: "the dashboard says 9am but it's 2pm" complaints, refresh schedules creeping toward hourly, and a refresh window that eventually overruns.

• DirectQuery chosen, speed needed: visuals spinning for ten seconds, the source DBA asking what is hammering production, and report designers stripping features to survive.

• Either chosen, scale arrived: models hitting memory ceilings, or DirectQuery sources timing out on billion-row scans.

Storage mode is a trade-off triangle: freshness, speed, scale - pick the two that matter.

When Is Import Still the Right Choice?

For the large majority of business reporting - finance packs, sales analysis, operations reviews - Import remains correct. Decisions made daily or weekly do not need second-by-second data; they need instant interactivity over trusted numbers, which is exactly what Import's engine delivers.

The discipline that keeps Import healthy at scale is incremental refresh and a properly shaped star schema: load only what changed, store only what is needed. A well-modelled Import dataset comfortably serves hundreds of users from surprisingly modest capacity - and is the architecture most performance optimisation work ultimately restores deployments to.

When Does DirectQuery Genuinely Earn Its Keep?

DirectQuery is justified when the business decision changes within minutes - warehouse pick monitoring, call-centre queues, intraday trading positions - or when data cannot be copied for sovereignty or licensing reasons. Outside those cases, it is usually chosen for an imagined freshness requirement nobody actually has.

If DirectQuery is genuinely required, design for it: aggregations so common visuals hit a small Import cache while detail queries pass through; a source tuned with the right indexes; and report pages built with restraint, because every visual on the page is a separate live query. The hybrid patterns - composite models mixing Import dimensions with DirectQuery facts - capture most of the freshness at a fraction of the pain.

What Does Direct Lake Change - and Who Should Care?

Direct Lake removes the choice between copying data and querying it: the model reads Delta tables in OneLake directly, with scan performance close to Import and no refresh window at all, because there is nothing to reload. For large estates on Microsoft Fabric, it dissolves the exact problem that forced compromise architectures.

Who should care: organisations whose models have outgrown refresh windows, whose data already lands in a lakehouse, or who are planning the move off Premium P-SKUs anyway. Direct Lake is a genuine reason heavy estates accelerate their Power BI to Fabric migration - the storage mode is the payoff for restructuring where data lands. The honest caveats: it requires Fabric capacity, data in Delta format, and certain features still cause fallback to DirectQuery behaviour - so it rewards estates built deliberately for it.

Which Mode Fits Which Scenario?

Match the mode to the decision cadence, not to the technology's marketing. The selection matrix below covers the common cases.

Scenario	Right mode	Why
Monthly finance pack, daily sales review	Import (+ incremental refresh)	Decisions are daily; interactivity matters more than minutes of freshness
Operations floor, queues, logistics tracking	DirectQuery with aggregations, or Direct Lake	Minutes genuinely change the decision
Billion-row event or telemetry analysis	Direct Lake (Fabric) or aggregated Import	Scale defeats refresh windows; lake formats carry it natively
Regulated data that cannot be copied	DirectQuery	Data residency at the source is the requirement
Mixed: stable history + live today	Composite / hybrid tables	Import the past, query the present

Can You Mix Storage Modes in One Model?

Yes - composite models exist precisely for this, and the strongest production pattern uses them deliberately. Detail tables stay in DirectQuery against the source while summary aggregation tables sit in Import: Power BI answers dashboard-level questions from the fast in-memory copy and only reaches back to the source when someone drills to row level.

The discipline is to treat mixing as a designed decision rather than an accumulation. Models that drift into composite mode - one analyst adds a DirectQuery table here, another imports a spreadsheet there - inherit the weaknesses of both modes and the strengths of neither, plus relationship limitations that surface as wrong totals in edge cases.

The practical rule: composite models earn their complexity when a genuine big-data detail layer meets a genuine interactive dashboard requirement. If your largest table fits comfortably in memory, a single-mode Import model remains simpler to build, faster to use and easier to hand over.

Direct Lake adds a third option to the mix for Fabric estates, with its own rule: it cannot participate in composite models today, so the choice there is architectural rather than per-table. Another reason the storage-mode decision belongs in the design review, not the build sprint.

Decide It Once, Deliberately

Storage mode is a decision that costs nothing to make well at design time and a great deal to unwind in production. The questions that decide it take an hour: how fresh do decisions actually require the data to be, how big will the facts grow, and where will the data land over the next three years?

Answer those honestly and the mode picks itself - Import by default, DirectQuery where minutes matter, Direct Lake where scale and Fabric meet. The deployments that struggle are rarely the ones that chose wrong; they are the ones that never noticed there was a choice.