Direct Lake vs Import vs DirectQuery: when to use each

Before Microsoft Fabric, picking storage mode in Power BI was a binary choice between Import (fast, refresh-bound) and DirectQuery (real-time, often slow). Direct Lake — released GA with Fabric — collapsed that trade-off for a large class of workloads. The decision tree we use on every Fabric engagement is straightforward once you know the constraints.

This post is the field guide we wish we had when Direct Lake first launched. It is opinionated on purpose. Many teams default to Import because it is familiar, then end up fighting refresh windows on datasets that have outgrown the pattern. Direct Lake is not always the answer, but it is the answer more often than most teams assume.

What each mode is actually doing

Import

Data is compressed and held in the in-memory VertiPaq engine. Query performance is excellent. The cost is refresh windows, dataset size limits per capacity, and the operational overhead of scheduled or incremental refresh. Import remains the right pattern for small, highly-aggregated datasets that fit comfortably in memory and where the refresh cadence is acceptable to the business.

DirectQuery

Every query is translated to SQL and run against the source system. There’s no refresh, but latency is bounded by source performance. Almost always worse than Import for interactive analytics; useful for compliance scenarios where data cannot be copied, or for cases where the source system is itself an analytical store optimized for ad-hoc queries (Synapse Dedicated SQL Pool, Snowflake, BigQuery).

Direct Lake

Data is read on-demand directly from Delta-parquet files in OneLake, without copying into VertiPaq. Query speed approaches Import for most workloads, with no refresh — because the source-of-truth files are the model. Available only in Microsoft Fabric, and constrained to data that is either landed in OneLake or shortcutted into it from Azure Data Lake Storage, Amazon S3, or other supported sources.

Composite models — the production sweet spot

On most serious Fabric engagements we are not picking a single mode. We are building composite models: Direct Lake for the large fact tables, Import for small aggregation tables that need to be present in memory at all times, and occasionally DirectQuery for a single auxiliary source that lives outside Fabric. The composite pattern gives sub-second response on billion-row facts while keeping the working set of measures and small dimensions hot. It is the highest-performance pattern we are shipping in production today.

The decision tree

• Source is in OneLake or shortcutted into it? Start with Direct Lake.
• Highly aggregated dataset under ~500MB compressed and refresh windows acceptable? Import.
• Hard regulatory requirement that data cannot leave the source system? DirectQuery (and accept the latency).
• Sub-second response on billion-row fact tables? Direct Lake or composite (Direct Lake + Import aggregations).
• Mixed source landscape with some data in OneLake and some elsewhere? Composite is almost certainly correct.
• Working with non-Fabric Power BI Premium? Direct Lake is unavailable — pick Import or DirectQuery.

Capacity SKU and model size constraints

Direct Lake behavior is tied to the capacity SKU the workspace runs on. Smaller SKUs cap the in-memory frame the engine can hold, which means very wide or very tall fact tables will fall back to DirectQuery for the visuals that exceed the frame. We always profile model size against the target SKU before committing to a Direct Lake design — fallback to DirectQuery on a slow lakehouse is the failure mode that surprises teams who skipped this step.

What to check against your capacity

• Frame size of the largest fact table in compressed form
• Cardinality of high-distinct-count columns (often the actual cost driver)
• Number of concurrent users and the working-set size during peak hours
• Whether the dataset will fit alongside other workloads on the same capacity
• Headroom for growth over the next 12-18 months

What changes operationally

Direct Lake retires the refresh job. The cost is that your data engineering pipeline becomes part of your BI SLA — if the upstream Delta tables aren’t reliable, the report breaks in user-visible ways. We always pair a Direct Lake adoption with a hardening pass on the upstream Data Factory or Spark pipelines, including freshness signals visible in the model, a clear escalation path when a pipeline fails, and a fallback dashboard mode that surfaces ‘data as of’ timestamps so executives are not surprised by silently stale numbers.

Migrating an existing Import model

We rebuild the model on Direct Lake rather than convert in place. Direct Lake has constraints (no calculated columns, no calculation groups in older capacities, no row-level Import-only patterns) that force a healthier modeling pattern anyway. Plan for two to four weeks per model depending on complexity, and run the new Direct Lake model in parallel with the existing Import model for at least one full reporting cycle to catch reconciliation drift.

Migration playbook

• Land the source data in OneLake (via Fabric Lakehouse, Data Factory, or shortcuts)
• Profile the largest tables for cardinality and width against the target capacity SKU
• Build a new Direct Lake semantic model — do not attempt in-place conversion
• Rebuild calculated columns as measures or push them into the source Delta tables
• Reconcile every executive KPI between the Import and Direct Lake models
• Run both models in parallel for one reporting cycle
• Cut over with a documented rollback plan to the Import model

What we wish we’d known earlier

• Direct Lake fallback to DirectQuery is invisible until users complain about slow visuals
• Cardinality matters more than total row count for in-memory frame sizing
• Calculation groups behave differently across Direct Lake versions — always pin the test on the target capacity SKU
• Pipeline reliability becomes a BI problem — get the data engineering team into the BI SLA conversation early
• Parallel-running Import and Direct Lake models is the cheapest insurance policy on a migration

The one-line takeaway

Direct Lake is the right default for serious Fabric workloads. Import is still the right answer for small, highly-aggregated, refresh-tolerant datasets. DirectQuery is a niche choice for compliance or for analytical-source-of-truth backends. The composite pattern is where the real wins live — and the migration discipline is what separates a successful Direct Lake adoption from one the executive team apologizes for in the next quarterly review.