Direct Lake vs Import vs DirectQuery: Choosing a Storage Mode in Microsoft Fabric

The storage mode of a semantic model decides where the data lives when a report runs — inside the model, at the source, or in OneLake. That one choice sets your query speed, your data freshness, your memory footprint, your load on source systems and a large part of your cost. It is not a setting to accept by default; it is an architecture decision to make per model.

Most teams pick by habit — Import, because that is what they have always used in Power BI — and only discover the consequences when a model is too large to refresh in the window, or a dashboard is stale, or a source database buckles under query load. An architect reverses that: start from the requirement — how much data, how fresh, how many concurrent users, how complex the model, what the source can bear — and let the requirement pick the mode.

Fabric gives three modes, and Direct Lake changed the calculus. Here is what each does, and the honest conditions on the newest one.

Import loads a copy of the data into the semantic model, compressed in memory. Queries then run entirely against that in-memory copy, which makes it the fastest mode for interactive reporting and the most forgiving of complex DAX and modelling. For most Power BI reports where the data can fit and a scheduled refresh meets the freshness need, Import is still the right answer.

The costs are refresh and memory. The data is only as fresh as the last refresh, so Import suits daily or hourly cadences, not live operations. And a large model consumes capacity memory and can outgrow its refresh window — a five-billion-row transaction table is where Import starts to hurt, and where teams reach for partitioning, incremental refresh, or a different mode entirely.

Import is the default to beat, not the default to assume. Beat it when the data is too large to refresh comfortably, or the freshness requirement is tighter than the refresh cadence can meet.

DirectQuery leaves the data at the source and queries it at runtime. Nothing is imported, so the model is always as fresh as the source and there is no refresh window to blow — which is why it is chosen where data cannot or should not be copied, or where near-live figures matter.

The costs are query speed and source load. Every visual becomes a query against the underlying system, so performance depends on the source and the model can feel slow under complex DAX or high concurrency. And you are pushing that query load onto the source database — a busy operational system may not welcome a dashboard sending it hundreds of queries a minute.

DirectQuery is a deliberate choice for freshness or data-residency reasons, made with eyes open to the performance and source-load trade-off — not a way to avoid thinking about model size.

Direct Lake is the Fabric-native mode and, for large models, often the most attractive. It reads Delta tables directly from OneLake — no traditional import step and no runtime query to a separate source. The result is near-Import query speed with near-DirectQuery freshness: as the Delta tables in the Gold layer update, the model reflects them without a refresh cycle.

The architecture that makes it work is the point. OneLake holds Gold Delta tables; the Direct Lake semantic model reads them; Power BI reads the model. Because the model and the data share OneLake, there is no copy to refresh and no external source to hammer. For a large analytical model on a well-built Gold layer, that combination is hard to beat.

This is why Direct Lake is usually the default worth reaching for on a Fabric-native estate — but "usually" is doing real work in that sentence, because it comes with conditions.

Direct Lake is not a free lunch, and an architect names the conditions rather than selling the mode. It works over Delta tables in OneLake, so it needs a well-built lakehouse Gold layer to read — point it at messy, un-optimised tables and the benefit evaporates. It also has capacity guardrails: very large queries or models can exceed limits, and certain modelling features are not supported in Direct Lake.

When a query crosses those guardrails or hits an unsupported feature, Direct Lake can fall back to DirectQuery for that query — which quietly reintroduces DirectQuery’s performance profile at the moment you least expect it. A model that "uses Direct Lake" but silently falls back under load is a common and frustrating surprise, and it is why you validate behaviour under realistic data and concurrency before trusting it in production.

So the honest position is: Direct Lake is excellent for large Fabric-native analytical models on a curated Gold layer, evaluated for fallback behaviour and capacity headroom — not a universal replacement that removes the need to think about model design.

Choose per model, on the requirement. Import when the data fits comfortably and a scheduled refresh meets the freshness need — still the right call for most reports. DirectQuery when data must stay live or cannot be copied, and you accept the query-speed and source-load trade-off. Direct Lake when you have a large model on a curated OneLake Gold layer and want Import-like speed with live freshness — validated for fallback and capacity.

Weigh the same factors every time: data volume, freshness requirement, concurrency, model complexity and source capability. Two models in the same estate can — and often should — use different modes. The 5-billion-row fact table on a Direct Lake model, the small live operational feed on DirectQuery, the departmental report on Import: one estate, three modes, each chosen for a reason.

The through-line for a Fabric architect is that the mode follows the workload, and the OneLake Gold layer underneath is what makes Direct Lake worth having at all. Build the Gold layer well, and the best mode is usually available to you; build it badly, and no storage mode rescues the report on top.