Power BI Direct Lake vs Import Mode: Performance, Refresh and Cost Trade-offs

Most Power BI storage-mode decisions are made on the wrong axis. The team asks "which mode is faster?" when the question that actually decides the outcome is "what breaks first at scale — the query, or the refresh?".

For a mid-market manufacturer running a semantic model over SAP, MES and quality data, the report that gets abandoned is almost never abandoned because a visual took three seconds instead of one. It gets abandoned because the overnight refresh failed at 6am and Wednesday morning is looking at Tuesday lunchtime data. Operations goes back to the ERP export, and the dashboard is dead.

Direct Lake and Import solve different halves of that problem. Import optimises the query. Direct Lake removes the refresh. Choosing between them is a judgement about which failure mode you are actually living with.

Import loads a compressed, in-memory copy of your data into the semantic model using the VertiPaq engine. Every query then runs against that copy — which is why Import is genuinely fast, and why it works against any source Power BI can connect to, from SQL Server to an Excel file on SharePoint.

The cost is the copy. That copy has to be rebuilt on a schedule — the refresh — and the refresh is where large operational models fail. A 50-million-row fact table that crossed the memory ceiling now takes four hours to refresh, times out under capacity pressure, and breaks roughly twice a month. The model is only ever as current as the last successful refresh.

For a 2-million-row finance model refreshed once a day, none of that matters and Import is the right answer. For a live production model that needs to reflect the last shift, the refresh window becomes the constraint the whole platform is designed around.

Direct Lake is a Microsoft Fabric storage mode that reads Delta-Parquet tables in OneLake directly into the semantic model, with no import and no DirectQuery translation to a source database. There is no separate copy to hydrate, so there is no refresh to schedule — as new data lands in the Delta table, the report reflects it.

The trade the documentation is honest about: Direct Lake needs the data in OneLake in Delta format, and certain model features or query shapes can cause a fallback to DirectQuery, which is slower. For a well-built operational model reading a curated gold layer, query latency sits within roughly 10–15% of Import — close enough that operations will not notice, and with the refresh window gone entirely.

This is why the pattern for a Microsoft-stack manufacturer is usually: land ERP, MES and quality data in OneLake through Mirroring or Azure Data Factory, model the gold layer in Delta, and read it in Power BI on Direct Lake. The semantic model stops being a copy that goes stale and becomes a live view over the lakehouse.

Everything else about the comparison is secondary to this. With Import you own a refresh window: a nightly job that has to finish before the working day, that consumes capacity while it runs, and that fails silently often enough that you build alerting around it. With Direct Lake there is no window, because there is no copy to rebuild.

The operational consequence is that "how fresh is the dashboard?" stops being a function of when the refresh last succeeded and becomes a function of when data last landed in OneLake. That moves the freshness problem upstream to the pipeline — which is where it belongs, and where it is easier to monitor.

We have taken four-hour refreshes to zero by moving the model to Direct Lake — not by tuning the refresh, but by removing it. Where a model has to stay on Import, the honest fix is almost never the gateway; it is bad DAX, a missing aggregation table, or an oversized model.

Import refresh consumes Fabric capacity — the hydration of that in-memory copy is real compute, and on a large model refreshed frequently it is a meaningful slice of your F-SKU. Direct Lake removes that hydration cost, so the same workload often runs comfortably on a smaller capacity.

In migrations we typically see the capacity bill drop 20–35% after moving large operational models off Import, because the refresh compute disappears and the model no longer has to be sized to hold the whole copy in memory. The caveat is honest: if your model is small, the refresh cost was already trivial and you will see no capacity saving — this lever only matters at scale.

The right way to size the move is to measure actual workload with the Fabric Capacity Metrics app before and after, not to guess at procurement time. The saving is real, but it is a consequence of removing hydration, not a headline discount.

Direct Lake is not a universal upgrade, and pretending otherwise is how you end up with a fallback-to-DirectQuery model that is slower than the Import model it replaced. Import still wins in three cases.

First, the source is not in OneLake and you do not want to land it there. Direct Lake requires Delta in OneLake; if the data lives in a source you are not mirroring, Import (or DirectQuery) is the connection you have.

Second, the model is small and simple. A few million rows refreshed once a day gets no benefit from removing a refresh that never fails, and Import gives you the broadest feature compatibility with zero fallback risk.

Third, the model relies on a pattern that triggers Direct Lake fallback — certain calculated-column or relationship shapes, or query volumes that exceed the guardrails. In those cases the model silently drops to DirectQuery and the latency advantage evaporates; Import is the predictable choice until the model is refactored.

The decision is not "Direct Lake is the future, migrate everything." It is a per-model call on two axes: is the data already in OneLake as Delta, and does the refresh window hurt?

If the answer to both is yes — the data lands in OneLake and the overnight refresh is the thing that breaks — move the model to Direct Lake and delete the refresh. If the data is not in OneLake, or the model is small and the refresh never fails, keep Import and spend the effort on DAX and aggregation instead.

For a mid-market manufacturer on Microsoft Fabric and Power BI, the highest-value version of this is usually a single governed gold model on Direct Lake for the live operational dashboards, with Import reserved for the small finance and month-end models where currency of data is measured in days, not minutes.

The insight arrives at the decision point. It does not sit in a report nobody opens because the refresh failed again.