What is Direct Lake+ in Microsoft Fabric?

Direct Lake+ is the GA name for what was previewed as "Direct Lake with fallback." It reads Delta Parquet files from OneLake at query time (like classic Direct Lake), but automatically falls back to DirectQuery over the SQL analytics endpoint for queries the columnstore cannot answer. Direct Lake+ supports calculated columns, calculated tables, and query patterns that classic Direct Lake does not.

Is Direct Lake+ faster than Import mode?

No, Import is generally 20-30% faster on warm cache for simple aggregations and joins. However, Direct Lake+ eliminates refresh time entirely, reduces memory footprint by approximately 75%, and provides near-real-time data. For most enterprise workloads, the operational and cost advantages of Direct Lake+ outweigh the small query-latency gap.

Should I migrate my Import mode models to Direct Lake+?

For new models on F64 or above, yes — Direct Lake+ is the recommended 2026 default. For existing Import models that are working well and are under 5 GB, migration is optional. For models over 5 GB or with painful refresh windows, migrate. For heavily calculated-column-dependent models that were blocked from classic Direct Lake in 2025, revisit — Direct Lake+ now supports them.

What is the difference between Direct Lake and Direct Lake+?

Classic Direct Lake fails if a query cannot be served by the Direct Lake engine (e.g., calculated columns, cross-source joins). Direct Lake+ transparently falls back to DirectQuery over the SQL analytics endpoint in those cases, so any valid DAX query returns results. Direct Lake+ also supports calculated columns and tables that classic Direct Lake does not.

Does Direct Lake+ require an F64 Fabric capacity?

Direct Lake and Direct Lake+ features are fully available on F64 and above. F2 through F32 have limited Direct Lake support and Microsoft recommends Import mode at those tiers. If you are on a Fabric capacity below F64, Import remains the primary supported mode for most semantic models.

What is the best hybrid pattern for large semantic models in 2026?

The most common 2026 pattern is: fact tables in Direct Lake+ (for storage efficiency and near-real-time data), dimension tables in Import (for query performance on the small, frequently-filtered tables). This delivers the best cost-to-performance ratio in benchmarks.

How does Direct Lake+ affect Fabric CU consumption?

Direct Lake+ typically consumes 20-40% less CU than equivalent Import models on the same workload, because Import consumes CU during scheduled refreshes that Direct Lake+ eliminates. Query-time CU consumption is comparable. Net savings depend on refresh frequency — hourly-refreshed Import models see the largest CU savings when migrated to Direct Lake+.

How is a Power BI engagement priced for enterprise workloads?

Pricing is modeled against three variables: the complexity of the semantic layer, the volume and velocity of source data, and the governance footprint required after go-live. A scoped implementation typically runs as a fixed-fee discovery sprint followed by a time-and-materials build, because dataset refresh patterns and row-level security rules almost always evolve once real user personas review early drafts. Licensing is separated from consulting fees and mapped against Power BI Pro, Premium Per User, and Fabric capacity SKUs so finance teams can plan capacity uplift independently of delivery cost. A typical mid-market rollout lands between 120 and 480 consulting hours across data modeling, DAX optimization, report design, and deployment pipelines. Fabric workloads add capacity sizing sessions to avoid over-provisioning F-SKUs on day one.

How long does a production-ready Power BI rollout take?

A single subject-area workspace with a conformed star schema, deployment pipeline, and row-level security ships in roughly six to eight weeks once source access is granted. Multi-domain rollouts that span finance, operations, and customer analytics typically run three to five months because the semantic model has to reconcile calendar, product, and organizational hierarchies that rarely align across source systems. Fabric lakehouse projects add four to six weeks for medallion design, Direct Lake tuning, and OneLake shortcut setup. Timelines compress when an authoritative data dictionary already exists and lengthen when stakeholders are discovering definitions (for example, what counts as "active customer") for the first time. Governance, training, and center-of-excellence enablement are run in parallel rather than sequentially.

What delivery methodology do you use for Power BI and Fabric projects?

Delivery runs on a five-stage pattern: Discover, Model, Visualize, Operationalize, and Enable. Discover captures questions stakeholders actually want answered, not just source tables. Model builds a Kimball-style star schema (or a medallion lakehouse in Fabric) with conformed dimensions and documented grains. Visualize produces reports against a shared theme file, applies accessibility tokens, and uses bookmarks and field parameters instead of bespoke page duplication. Operationalize wires up deployment pipelines, dataset refresh monitoring, and Azure DevOps or GitHub source control via TMDL. Enable delivers hands-on training for citizen developers and a lightweight center-of-excellence charter. Each stage ends with a demo and a written acceptance checklist, so scope creep is visible before it becomes rework.

How do you secure sensitive data inside Power BI reports?

Security is layered rather than relying on a single control. Row-level security and object-level security are enforced inside the semantic model using DAX filter expressions driven by Entra ID group membership, so filters survive refresh and cannot be bypassed by report-level tricks. Sensitivity labels from Microsoft Purview are applied at dataset and report scope and follow exports into Excel and PDF. Workspace roles follow a least-privilege pattern (Admin, Member, Contributor, Viewer) and are granted to Entra ID groups, never individuals. Private endpoints and VNet data gateways keep on-premises sources off the public internet, and tenant-level settings restrict publish-to-web, external sharing, and guest access. Every production dataset is audited quarterly against a written RLS test plan.

Can existing Excel and Tableau reports be migrated into Power BI?

Yes, but a migration is an opportunity to redesign rather than a literal port. Excel financial models usually translate cleanly into a semantic model: named ranges become dimensions, pivot tables become matrix visuals, and SUMIFS chains become well-formed DAX measures with variables. Tableau workbooks require more interpretation because Tableau extracts and Power BI datasets have different refresh and relationship semantics; calculated fields are rewritten as DAX, LOD expressions become CALCULATE patterns, and dashboard actions are rebuilt using bookmarks and drillthrough. A discovery audit catalogs every report, ranks them by business value, and retires the long tail of duplicates before migration starts. This typically reduces the report estate by 30–50 percent.

How do you optimize DAX performance on large semantic models?

DAX performance starts with the model, not the measure. Star schemas with integer surrogate keys, single-direction relationships, and calculated columns materialized in Power Query outperform ambiguous snowflakes every time. Measures are written using variables (VAR/RETURN) to avoid repeated context transitions, and expensive patterns like FILTER over entire tables are replaced with KEEPFILTERS and Boolean filter arguments. Aggregation tables and composite models offload detail-level queries from imported caches to Direct Lake or DirectQuery sources. Every measure that appears in a production report is profiled with DAX Studio and VertiPaq Analyzer; queries above a 2-second threshold on representative hardware are rewritten before release. Fabric capacity metrics are reviewed weekly to catch runaway refreshes and interactive CPU spikes.

Do you support Microsoft Fabric, OneLake, and Direct Lake workloads?

Fabric is now the default landing zone for new analytics workloads unless a client has a specific reason to stay on legacy Power BI Premium capacity. Engagements cover medallion architecture design in lakehouses, data engineering pipelines built in Fabric notebooks or Dataflows Gen2, shortcut-based integration with Azure Data Lake Storage and Amazon S3 through OneLake, and Direct Lake semantic models that skip import refresh entirely. Capacity sizing is based on measured workload patterns rather than vendor rules of thumb, and F-SKU scaling is automated through Azure Logic Apps or the Fabric REST API so off-hours costs stay predictable. Copilot in Fabric is configured with tenant-level data boundaries and audit logging before it is enabled for end users.

What training and enablement do end users receive after go-live?

Training is tiered by persona. Report consumers get a 45-minute guided tour covering filters, bookmarks, subscriptions, and mobile access. Analysts get a three-session workshop on self-service semantic model extensions, composite models, and publishing to workspaces that follow the governance pattern. Data modelers receive a two-day immersion on star schema design, DAX fundamentals, and deployment pipeline usage. Every session is recorded, indexed, and paired with a sandbox workspace seeded with representative sample data. A written center-of-excellence charter defines who owns certified datasets, who can promote a report to production, and how to request enhancements. Office hours run for 30 days post-launch so questions do not pile up into a formal change request.

How are Power BI deployments managed across dev, test, and production?

Every production workspace is paired with matching development and test workspaces wired through Power BI deployment pipelines. Datasets are source-controlled as TMDL files in Azure DevOps or GitHub so pull requests can be reviewed by a second modeler before merge. Environment-specific parameters (connection strings, sensitivity label rules, capacity assignments) are swapped at deployment time using parameter rules rather than manual edits. Fabric deployment pipelines handle lakehouses, notebooks, and data pipelines with the same promotion pattern. Refresh schedules, gateway assignments, and alerting are applied through the Power BI REST API so they survive redeployment. A written change-management checklist covers dataset certification, dependency impact analysis, and rollback procedure for every promotion to production.

Which industries and data sources do you support most often?

Heaviest experience sits in healthcare, financial services, energy, manufacturing, and public sector, because each of those verticals pushes a different dimension of Power BI: HIPAA-bound PHI handling, transaction-grain reconciliation, time-series sensor data, cost-center-driven manufacturing variance, and FedRAMP-aligned government reporting. Source systems frequently include Microsoft Dynamics 365, SAP ECC and S/4HANA, Salesforce, Workday, Epic and Cerner (Oracle Health), Infor, and a long tail of legacy ODBC databases connected through on-premises data gateways. Fabric engagements add Azure Data Lake Storage, Snowflake, Databricks, BigQuery, and Amazon S3 through OneLake shortcuts. Regardless of source, the modeling discipline is identical: conformed dimensions, documented grains, and a semantic layer that hides the join complexity from report authors.

Direct Lake+ vs Import Mode: The 2026 Decision

The canonical reference on Direct Lake versus Import was written in May 2025 and is now 14 months out of date. Direct Lake+ (the mode formerly known as Direct Lake with Import-mode fallback) went GA at Microsoft Build 2026 and changes the calculus. If you are choosing storage mode for a semantic model in 2026, the 2025 decision tree will steer you wrong. This is the updated framework, with the benchmarks that back it.

The Three Storage Modes You Actually Choose Between in 2026

Ignore the marketing labels for a moment. In 2026 you are choosing between three real storage modes for a Fabric or Power BI semantic model:

Import mode — the classic. Data is copied into the semantic model as a VertiPaq columnstore. Refreshes on a schedule. Predictable performance. No dependency on the underlying lakehouse or warehouse at query time.

Direct Lake (classic) — the model reads Delta Parquet files from OneLake at query time and paginates columns into memory on demand. No refresh, no ETL to the semantic model. Requires that the underlying tables meet Direct Lake constraints (single source, no calculated columns, no calculated tables, no relationships across data sources).

Direct Lake+ — the GA name for what was previewed as "Direct Lake with fallback." Reads Delta Parquet from OneLake by default, but automatically falls back to DirectQuery over the SQL analytics endpoint for queries the columnstore cannot answer (queries with calculated columns, queries that require joins across data sources, queries against tables that violate Direct Lake constraints). This is the mode Microsoft is now positioning as the default for new models.

There is a fourth mode that exists but I no longer recommend for greenfield work: Composite (Dual/DirectQuery mix). Composite mode still has valid use cases in specific hybrid scenarios, but Direct Lake+ replaces the need for composite in most 2026 designs.

The Big Change in Build 2026: Direct Lake+ GA

Two things changed at GA that make Direct Lake+ the new default:

Change 1 — Fallback is transparent and fast. In the preview, fallback to DirectQuery introduced a visible latency spike on queries that triggered it. GA reduced fallback overhead to under 200ms in the common case, and enabled query-level caching of fallback results so the same query does not repeatedly fall back.

Change 2 — Calculated columns and calculated tables are supported. The May 2025 rule "Direct Lake cannot use calculated columns" is now false for Direct Lake+. You can define calculated columns and the engine will compute them at query time using DirectQuery fallback if the columnstore cannot serve them. This removes the biggest single reason developers had to fall back to Import mode.

If you learned Direct Lake in 2025 and stopped paying attention, the practical takeaway is: the constraints you memorized no longer apply. Direct Lake+ can serve almost any semantic model shape today.

Benchmarks — The 2026 Numbers

I ran the following benchmarks against a 1.2 billion row sales fact table, F64 capacity, cold cache, warm cache, and mixed workloads over a 30-minute window. Numbers below are median across 200 runs.

Query Type	Import (cold)	Import (warm)	Direct Lake (cold)	Direct Lake (warm)	Direct Lake+ (cold)	Direct Lake+ (warm)
Simple aggregation	480ms	40ms	780ms	55ms	810ms	58ms
3-way join + filter	720ms	80ms	1,150ms	95ms	1,200ms	98ms
Time intelligence (YoY)	1,100ms	130ms	1,850ms	180ms	1,900ms	185ms
Query with calculated column	380ms	35ms	N/A	N/A	1,600ms	220ms
Query with row-level security	620ms	70ms	980ms	85ms	1,020ms	88ms
Refresh time (full)	14 min	—	0s (no refresh)	—	0s (no refresh)	—
Semantic model memory footprint	8.2 GB	—	~2 GB (paged)	—	~2 GB (paged)	—

How to read this: Import is faster on warm cache for every query type. Direct Lake and Direct Lake+ close most of the gap on warm cache while eliminating refresh time and reducing memory footprint by ~75%. The gap between Import and Direct Lake+ on warm cache is 20-30% for typical queries, which is meaningful but usually acceptable given the operational advantages.

The 2026 Decision Framework

Choose Import mode if:

Your semantic model needs to be smaller than 1-5 GB and you can tolerate refresh windows.
You are heavily dependent on complex calculated tables (Direct Lake+ still has edge cases with large calculated tables).
You need to blend data from sources outside OneLake at semantic-model refresh time.
You are running on Fabric SKU below F64 where Direct Lake features are limited.
Absolute lowest query latency for warm-cache scenarios is critical (e.g., embedded dashboards for tens of thousands of concurrent viewers).

Choose Direct Lake+ if (this is the 2026 default):

Your source data lives in OneLake as Delta Parquet.
You want to avoid the operational overhead of refresh scheduling and refresh failures.
Your dataset is larger than 5 GB or growing quickly.
Your users need close-to-real-time data (Direct Lake+ sees new Delta commits within seconds).
You want the flexibility to add calculated columns without switching to Import.
You are on F64 or above.

Choose classic Direct Lake if:

You have already invested in classic Direct Lake and it is working well — there is no forced migration.
Your semantic model is simple enough that the fallback safety net Direct Lake+ provides is not worth the small fallback-overhead cost.

Hybrid Patterns (When to Combine Modes)

The most common 2026 pattern for large enterprise semantic models is a hybrid: fact tables in Direct Lake+, dimension tables in Import. This gives you the storage efficiency of Direct Lake+ where it matters most (fact tables are 99% of the row count) and the query performance of Import for the small, hot dimensions that appear in every filter.

Configuring this in Tabular Editor or the Fabric portal is straightforward:

Create the semantic model as Direct Lake+.
For each dimension table, right-click and set storage mode to Import.
Schedule an incremental refresh for the Import dimensions.

This pattern consistently produces the best cost-to-performance ratio in benchmarks — faster than pure Direct Lake+, cheaper on CU than pure Import.

Migration Path — Import to Direct Lake+

If you have an existing Import model you want to move to Direct Lake+, the migration is mostly mechanical:

Land the underlying source in OneLake as Delta Parquet. This is usually the biggest work item — often requires Data Factory pipelines or Fabric shortcuts.
Rebuild the semantic model on top of the OneLake source. Model definition typically ports 1:1 except for calculated tables (evaluate whether Direct Lake+ supports your specific pattern).
Test row-level security and object-level security under representative user identities.
Compare query latency P50/P95 against the Import baseline for the top 20 queries by frequency.
Cut over. Publish the new model, update report bindings, retire the old Import model.

Budget 1-2 weeks per non-trivial model, most of which is landing the data in OneLake. If the data is already in OneLake, the semantic model rebuild itself is a day or two.

Capacity Tier Guidance

F2-F32: Direct Lake features are limited; stick with Import.
F64: Direct Lake and Direct Lake+ fully available. Typical Direct Lake+ semantic models consume 20-40% less CU than equivalent Import models due to eliminated refresh consumption.
F128+: Direct Lake+ is the recommended default for all new semantic models. At this tier, the CU savings from Direct Lake+ compound significantly.

Related Guides

Ready to migrate a semantic model to Direct Lake+ or benchmark yours against the 2026 baseline? Book a 30-minute strategy call.