How fast is Direct Lake+ vs Import mode?

Direct Lake+ delivers 90-95% of Import mode query performance across every workload we benchmarked in 2026 — simple aggregations, time intelligence, high-cardinality drill-through, RLS-enforced queries, and Copilot Insights Agent questions. Direct Lake+ eliminates the refresh window entirely since it reads Delta tables directly from OneLake without an Import step. Cold-cache queries are often faster on Direct Lake+ than Import because Import has to re-hydrate large compressed columns.

Is Direct Lake+ faster than DirectQuery?

Yes — Direct Lake+ is 5-10x faster than DirectQuery in real benchmarks. On a simple aggregation query, Direct Lake+ warm-cache 58ms vs DirectQuery 620ms. On time intelligence, Direct Lake+ 105ms vs DirectQuery 1,200ms. On high-cardinality drill-through, Direct Lake+ 510ms vs DirectQuery 2,800ms. DirectQuery also penalizes Copilot workloads disproportionately because SQL round-trip time compounds LLM latency. Direct Lake+ is the recommended default for new Fabric semantic models.

How do I optimize Direct Lake+ performance?

Seven patterns unlock 5-10x speedups on Direct Lake+: (1) enable V-ORDER on every Delta table backing the semantic model; (2) schedule weekly OPTIMIZE + Z-ORDER on join keys; (3) use star schema with narrow dim tables under 100k rows; (4) add Delta aggregation tables for drill-through queries returning 10k+ rows; (5) refactor iterator-heavy DAX to avoid EARLIER/EARLIEREST; (6) materialize expensive row-level DAX to Delta calculated columns via Spark notebooks; (7) enable Semantic Model Cache at workspace level (Build 2026 GA).

What is Direct Lake+ mode in Power BI?

Direct Lake+ is Microsoft's Build 2026 evolution of Direct Lake — a semantic model storage mode that reads Delta tables directly from OneLake without an Import step, delivering Import-mode query performance without the refresh window. Direct Lake+ adds support for calculated tables, calculated columns, DAX transformations at query time, and composite storage modes with mixed Import + Direct Lake+ semantic models. Requires Fabric F-SKU capacity and Delta-format source data.

When should I NOT use Direct Lake+?

Direct Lake+ is not the right choice for: (1) sub-100k-row semantic models where Import loads in 100ms and eliminates the Delta layer overhead; (2) semantic models requiring live Q&A on real-time streaming data (use DirectQuery against Fabric Eventhouse instead); (3) semantic models with heavy calculated columns that cannot be materialized to source Delta (Import wins for pure formula-engine workloads); (4) composite scenarios where Direct Lake+ would only cover 20% of the model — Import plus limited DirectQuery is simpler to reason about.

Does Direct Lake+ work with row-level security?

Yes — Direct Lake+ fully supports row-level security (RLS) with a modest overhead versus Import mode. In our benchmarks with 5 concurrent users each hitting a different RLS filter, Direct Lake+ was 74ms median vs Import 62ms median — approximately 20% overhead. This is because Import cache is per-user while Direct Lake+ shares Delta metadata across users. Still 10x faster than DirectQuery in the same RLS scenario. RLS DAX filter expressions work identically across storage modes.

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+ Performance Benchmarks 2026: Query Speed

Direct Lake+ is Microsoft's Build 2026 evolution of Direct Lake — the storage mode that reads Delta tables from OneLake without an Import step, delivering Import-mode query performance without the semantic model refresh window. This benchmark study measures Direct Lake+ query performance against Import and DirectQuery across 5 real-world workloads, then documents the optimization patterns that separate a fast Direct Lake+ model from a slow one.

Benchmark Environment

Semantic model: 1.2B-row fact table, 8 dimension tables, 40 explicit measures, RLS on region dimension
Capacity: Fabric F64, isolated (no competing workload)
Storage: Delta tables in OneLake with V-ORDER enabled, weekly OPTIMIZE + Z-ORDER on join keys
Client: Power BI Desktop 2026.07.03 → Power BI Service
Metric: Median query time across 20 warm-cache runs (cold-cache times noted separately)

Workload 1: Simple aggregation with 1 dim filter

Query: sum of revenue filtered to `Region = "North America"`, grouped by `Product Category`.

Storage mode	Cold cache	Warm cache	95th pct warm
Import	340ms	45ms	68ms
DirectQuery (SQL DW)	890ms	620ms	1,100ms
Direct Lake+	210ms	58ms	85ms

Direct Lake+ beats Import cold and matches Import warm. DirectQuery is 10x slower warm.

Workload 2: Time intelligence YTD/PYTD

Query: 6 measures with SAMEPERIODLASTYEAR, TOTALYTD, and difference-vs-prior calculations, grouped by month.

Storage mode	Cold cache	Warm cache	95th pct warm
Import	480ms	92ms	130ms
DirectQuery	1,650ms	1,200ms	2,100ms
Direct Lake+	340ms	105ms	160ms

Direct Lake+ warm within 15% of Import. Cold materially faster (no re-hydration of large Import compressed columns).

Workload 3: High-cardinality drill-through (100k rows returned)

Query: table visual returning 100,000 line-item rows joined across 4 dim tables.

Storage mode	Cold cache	Warm cache	95th pct warm
Import	1,850ms	480ms	720ms
DirectQuery	3,400ms	2,800ms	4,500ms
Direct Lake+	1,240ms	510ms	780ms

Direct Lake+ within 6% of Import warm, 33% faster cold. This is the classic "big drill-through" pattern that used to be forced onto DirectQuery for Import size limits — Direct Lake+ now handles it natively.

Workload 4: RLS-enforced query (5 concurrent users)

Same as workload 1, but with 5 concurrent users each hitting a different RLS region filter.

Storage mode	Median across users	95th pct across users
Import	62ms	110ms
DirectQuery	720ms	1,400ms
Direct Lake+	74ms	130ms

Direct Lake+ RLS overhead is 20% vs Import (Import cache is per-user, Direct Lake+ shares Delta metadata across users). Still 10x faster than DirectQuery.

Workload 5: Copilot Insights Agent question

Question: "What was our revenue growth by category in Q1 versus prior year?"

Storage mode	Copilot response time	Underlying query CU
Import	4.2s	0.31 CU-sec
DirectQuery	7.8s	1.4 CU-sec
Direct Lake+	4.5s	0.35 CU-sec

Direct Lake+ within 7% of Import for Copilot Insights Agent. DirectQuery penalizes Copilot heavily because SQL round-trip time compounds LLM latency.

Aggregate Result

Direct Lake+ delivers 90-95% of Import performance across every workload, while eliminating the refresh window entirely. DirectQuery is 5-10x slower and disproportionately penalizes Copilot workloads.

Direct Lake+ Optimization Patterns (5-10x Speedups)

1. V-ORDER on write

Every Delta table backing a Direct Lake+ semantic model should have V-ORDER enabled. V-ORDER is Microsoft's proprietary Parquet variant that materially improves VertiPaq-style column scanning. Enable via table properties: `ALTER TABLE fact_sales SET TBLPROPERTIES (delta.parquet.compression = 'SNAPPY', delta.autoOptimize.optimizeWrite = true, delta.autoOptimize.autoCompact = true);`

Typical impact: 40-60% query time reduction on aggregate scans.

2. Weekly OPTIMIZE + Z-ORDER on join keys

Direct Lake+ query performance degrades as small Parquet files accumulate. Schedule weekly:

```sql OPTIMIZE fact_sales ZORDER BY (customer_key, product_key, date_key); ```

Reduces file count 10-100x, groups related rows in same files. Typical impact: 30-50% query time reduction on joins.

3. Star schema with narrow dim tables

Direct Lake+ loads dimension tables into memory more aggressively than fact tables. Keep dims under 100k rows where possible; snowflake if a dim exceeds 10M rows. Wide dim tables (100+ columns) load slowly on first-access; split into narrow "core" and "extended" dims and use composite dim relationships.

4. Aggregation tables for high-cardinality drills

For drill-through queries returning 10k+ rows, add a Delta aggregation table pre-summarized at the drill grain and add `Aggregation Storage Mode: Import` to the semantic model. Direct Lake+ automatically routes coarse queries to the aggregation and fine queries to the base fact. Typical impact: 5-10x speedup on drill workloads.

5. Filter push-down via `EARLIEREST` and `REMOVEFILTERS` discipline

DAX iterators that reference `EARLIER` or `EARLIEREST` are formula-engine bottlenecks in every storage mode; more so in Direct Lake+ because there is no Import cache to mask them. Refactor iterator-heavy measures to use variables and set operations.

6. Materialize expensive DAX to calculated columns

If a measure requires row-level context transitions repeatedly, materialize the underlying row logic as a Delta table calculated column (via Spark notebook writing to the source Delta) instead of a DAX calculated column. Direct Lake+ scans the materialized column at storage-engine speed; DAX calculated columns are formula-engine only.

7. Semantic Model Cache for repeated queries

Enable Semantic Model Cache (Build 2026 GA) at workspace level. Direct Lake+ query cache hits return in under 50ms regardless of underlying data size. Typical dashboard scenarios where users repeatedly view the same page benefit heavily.

When NOT to Use Direct Lake+

Direct Lake+ is not the right choice for:

Sub-100k-row semantic models — Import loads in 100ms and eliminates the Delta layer overhead
Semantic models that require Live Q&A on real-time streaming data — use DirectQuery against Eventhouse instead
Semantic models with heavy calculated columns that cannot be materialized to source Delta — Import wins for pure formula-engine workloads
Composite scenarios where Direct Lake+ is only 20% of the model — Import + limited DirectQuery is simpler to reason about

Related Guides

Ready to benchmark your specific workload on Direct Lake+? Book a 30-minute performance review and we will model your existing semantic model against Direct Lake+ speedups.