DP-600 Exam Topic · Skills Measured April 2026

DP-600 Direct Lake Performance Optimization

Direct Lake is the highest-impact DP-600 topic for performance questions. This guide covers the OneLake vs SQL endpoint decision, every fallback trigger, all three DirectLakeBehavior settings, Delta table optimization with V-Order and Z-Order, DAX patterns for Direct Lake, capacity guardrails per F-SKU, and 18 exam-style questions with full explanations.

DP-600 Direct Lake — the quick answer

Direct Lake reads Delta-Parquet files from OneLake directly via VertiPaq — no data import, no per-query SQL. It appears in DP-600 under ‘Implement and manage semantic models’ (25–30%), specifically: configure Direct Lake including default fallback and refresh behavior; choose between Direct Lake on OneLake and Direct Lake on SQL endpoints; improve DAX performance; implement performance improvements in queries and report visuals. (per official DP-600 Skills Measured, April 20, 2026)

📋 DP-600 Domain: Implement & Manage Semantic Models (25–30%) · Optimize Enterprise-Scale Semantic Models

📅 Skills measured updated: April 20, 2026 ⏱ Read time: ~16 min ✍️ A.J., Data Engineering Researcher 🔗 Official DP-600 Study Guide

Section 01

What Direct Lake Is and Why It Matters for DP-600

Power BI has three storage modes. Import copies data into the VertiPaq in-memory engine — fast queries, but a refresh cycle that means reports can be hours behind the source. DirectQuery runs a live SQL query against the source on every report interaction — always current, but slow for large datasets. Direct Lake sits between the two.

Direct Lake reads Delta-Parquet files directly from OneLake using the VertiPaq engine. No data copy. No per-query SQL translation. VertiPaq frames the Delta files — mapping them into its in-memory column store format — and then serves queries from that framing at near-Import speed. When the underlying Delta files change, VertiPaq re-frames automatically. Reports stay current without an import refresh cycle.

This is why Direct Lake is the highest-impact storage mode for large-scale analytics in Fabric, and why it appears prominently in the DP-600 exam under Optimize enterprise-scale semantic models. The exam tests whether you can choose the right configuration, diagnose why Direct Lake fell back to DirectQuery, and design Delta tables that keep VertiPaq performing at its best.

📌

Direct Lake Availability — F64 Minimum for Production

Direct Lake requires a Fabric capacity. For production workloads at enterprise scale, F64 is the recommended minimum. Smaller F-SKUs (F2, F4, F8, F16, F32) support Direct Lake but with tighter row count and file count limits. The DP-600 exam tests capacity guardrail knowledge — know the limits for F64, F512, and F1024.

Section 02

OneLake vs SQL Endpoint — The Core DP-600 Architecture Decision

The most frequently tested Direct Lake design question in DP-600: should you connect your semantic model to Direct Lake on OneLake, or to Direct Lake via a SQL endpoint? The answer determines your fallback risk profile completely.

✅ Direct Lake on OneLake

VertiPaq reads Delta files directly from OneLake storage
No SQL layer in the data path
Zero SQL-based fallback triggers
Supports 10B+ row fact tables at F1024
Security managed at OneLake item level
Predictable sub-second performance
Choose when: You control the Lakehouse design and can manage security with OneLake item-level permissions

⚠️ Direct Lake via SQL Endpoint

SQL analytics endpoint sits between VertiPaq and Delta files
Introduces SQL-specific fallback triggers
Row-Level Security defined in SQL causes fallback
Non-materialized views cause fallback
Supports complex SQL RLS and warehouse security
Performance depends on fallback frequency
Choose when: Existing SQL RLS or complex view logic cannot be removed

Decision Factor	OneLake	SQL Endpoint	DP-600 Answer
SQL-based fallback risk	None — no SQL layer	RLS and views can trigger it	OneLake for strict SLA
Row count scalability	10B+ rows at F1024	Best under 1.5B at F64	OneLake for very large tables
Row-Level Security	OneLake item-level only	Full SQL RLS supported	SQL endpoint if SQL RLS required
View support	Materialized views only	Non-materialized views risky	Prefer materialized views either way
Security complexity	Simpler — item-level	Complex — SQL grants + RLS	OneLake unless SQL RLS is mandatory
Performance predictability	Always VertiPaq	Depends on fallback frequency	OneLake for consistent response times

The DP-600 exam presents this as a scenario: “A team has a 2.5 billion row fact table in a Fabric Lakehouse. Power BI reports are intermittently slow. Investigation shows DirectQuery fallback is occurring.” The correct answer path: the table exceeds F64 guardrails, OR Row-Level Security defined in the SQL endpoint is triggering fallback, OR the connection is via SQL endpoint with non-materialized views. The fix: connect directly to OneLake, ensure the table is under the F-SKU row limit, or upgrade the capacity.

Section 03

Every Direct Lake Fallback Trigger — What Causes It and How to Fix It

Understanding every fallback trigger is the most important Direct Lake exam skill. Fallback is silent by default — the report just gets slower. The exam presents symptoms and expects you to identify the cause.

Fallback Trigger	Via OneLake?	Via SQL Endpoint?	Fix
Row-Level Security defined in SQL	No — not applicable	Yes — causes fallback	Switch to OneLake connection, or implement RLS in Power BI semantic model instead of SQL
Non-materialized views	No — not applicable	Yes — causes fallback	Replace non-materialized views with materialized views, or materialize the view result as a Delta table
Row count exceeds F-SKU limit	Yes	Yes	Upgrade F-SKU, archive old partitions, or split very large tables
Parquet file count exceeds limit	Yes	Yes	Run OPTIMIZE to consolidate small files. Target <200 files per partition.
Unsupported column data types	Yes	Yes	Cast to supported types in the Silver/Gold transformation layer before the data reaches the semantic model
Complex query features VertiPaq cannot process natively	Yes	Yes	Simplify DAX. Push complexity into the Gold layer as pre-calculated columns rather than on-the-fly DAX computation.

🚨

Critical: Fallback Still Happens When DirectLakeBehavior = DirectLakeOnly — for Capacity Breaches

When a Direct Lake table exceeds F-SKU row count or file count limits, Fabric falls back to DirectQuery even when DirectLakeBehavior is set to DirectLakeOnly. Capacity guardrail breaches override the behavior setting. This is a common DP-600 trick question: “A team set DirectLakeBehavior to DirectLakeOnly but reports are still slow. Why?” — Answer: the table exceeded the F-SKU row or file count limit, triggering a capacity-forced fallback that the behavior setting cannot override.

Section 04

DirectLakeBehavior — The Three Settings and When to Use Each

DirectLakeBehavior is a semantic model-level property. It controls what the engine does when a query would normally fall back from Direct Lake to DirectQuery. DP-600 tests all three settings with scenario-based questions — know which setting to choose given the business requirement.

DirectLakeBehavior property — three options

// Set in Tabular Model Definition (.tmdl) or via XMLA endpoint// Option 1 — DEFAULT. Allows graceful fallback to DirectQuery silently model DirectLakeBehavior = “Automatic”;// Option 2 — Returns an error instead of falling back. Issues surface in testing. model DirectLakeBehavior = “DirectLakeOnly”;// Option 3 — Returns empty result set on fallback. No error, no slow query. model DirectLakeBehavior = “DirectLakeOrEmpty”;

Setting	What Happens on Fallback	Use When	DP-600 Exam Signal
Automatic	Silently falls back to DirectQuery. Query succeeds but is slower.	Exploratory analytics where occasional slow queries are acceptable. Analysts prefer an answer over an error.	Question uses words like “must never fail” or “user experience must not be interrupted” → Automatic
DirectLakeOnly	Returns an error instead of falling back. Query fails visibly.	Production environments with strict SLAs where slow fallback is worse than failure. Forces issues to surface in testing before production.	Question uses words like “predictable performance,” “SLA,” “errors should be visible during testing” → DirectLakeOnly
DirectLakeOrEmpty	Returns an empty result set instead of falling back. No error, no data.	Regulatory dashboards where showing incorrect/stale data is more harmful than showing blank. Used when a security policy change is mid-update.	Question uses words like “data correctness over availability,” “blank is better than wrong data” → DirectLakeOrEmpty

Section 05

Delta Table Optimization for Direct Lake — V-Order, Z-Order, OPTIMIZE

Direct Lake performance starts at the Delta table level. A semantic model reading poorly structured Delta files will underperform regardless of how well the DAX is written. Three Delta-level optimizations are tested on DP-600.

V-Order — Column-Store Compression

V-Order is a Microsoft-specific optimization applied when writing Parquet files. It rearranges data within each Parquet file to be more column-store friendly — tighter dictionary encoding, better compression, higher VertiPaq cache hit rates. V-Order is applied by the Spark engine in Fabric by default for Delta tables created through Fabric Notebooks and Dataflow Gen2. It can also be applied explicitly via OPTIMIZE.

Z-Order — Co-locate Related Data

Z-Order re-clusters data on specified columns — typically the join keys used in your semantic model (CustomerKey, ProductKey, DateKey). Co-locating similar key values in the same Parquet files means VertiPaq can skip more files when filtering, making predicate pushdown more efficient.

Row Group Sizing

Per Microsoft Learn, optimal row group size for Direct Lake is 1 million to 16 million rows, with approximately 4 million as the practical target. Too small: metadata overhead increases. Too large: individual segments become expensive to cache. The 4M row target balances compression ratio against cache granularity.

OPTIMIZE with V-Order and Z-Order — Gold layer fact table

— Apply V-Order compression and Z-Order co-location on Gold fact table
— Run after each incremental load or on a weekly scheduleOPTIMIZE gold.fact_sales
ZORDER BY (CustomerKey, ProductKey, DateKey)
VORDER;

Target file count check — keep under 200 per partition

— Check file count per partition before and after OPTIMIZE
SELECT
partition_values,
COUNT(*) AS file_count,
SUM(size) / 1048576 AS total_size_mb
FROM (DESCRIBE DETAIL gold.fact_sales)
— Also available in Delta Lake history:
DESCRIBE HISTORY gold.fact_sales LIMIT 5;

⚠️

OVERWRITE is Expensive for Direct Lake — Prefer MERGE or APPEND

OVERWRITE invalidates existing segment metadata and dictionaries. VertiPaq must rebuild the dictionary mapping the next time the table is framed, increasing CPU cost and temporarily pushing columns to Cold residency. For production Gold tables feeding Direct Lake semantic models, use incremental MERGE or APPEND patterns. Reserve OVERWRITE for initial loads or full rebuilds during maintenance windows.

Section 06

DAX Performance Patterns for Direct Lake Semantic Models

Delta table optimization handles the storage side. DAX optimization handles the query side. These patterns apply specifically to Direct Lake where VertiPaq reads from Delta files rather than imported data — the engine behavior is similar but the fallback risk means inefficient DAX can compound into fallback triggers.

Replace Text Keys with Integer Surrogate Keys

Text columns create large dictionaries — every distinct value must be stored and tracked. Integer surrogate keys (CustomerKey as INT vs CustomerName as VARCHAR) have dictionaries 10–100× smaller. Smaller dictionaries: more data stays in VertiPaq cache, joins complete faster, memory pressure drops.

Use Predicate Pushdown — Filters Before Aggregation

Apply filters at the visual or page level (slicers, page filters) rather than wrapping large tables in FILTER() inside measures. Direct Lake can skip entire Parquet files when filters are applied early — a visual-level filter that eliminates 80% of data means 80% fewer segments are read before aggregation starts.

Start with Simple Aggregations Before Iterators

SUM(), COUNT(), AVERAGE() map directly to storage engine queries that Direct Lake handles efficiently. SUMX(), COUNTX(), and other X-function iterators create row-by-row evaluation that forces more segment reads. Build the measure with a simple aggregation first; add iterators only when business logic requires them and no storage engine alternative exists.

Hybrid Tables for RLS-Heavy Dimensions

Keep very large fact tables in Direct Lake mode. Load sensitive, security-complex dimensions in Import mode. Import mode supports complex Row-Level Security, calculated columns, and user-friendly hierarchies without affecting Direct Lake performance on the main fact table. The VertiPaq engine handles both modes within the same semantic model.

DAX — simple measure before iterator version

— Prefer this: maps directly to storage engine SUM
Total Revenue = SUM(fact_sales[Revenue])— Over this when avoidable: row-by-row iterator forces more segment reads
Total Revenue Slow = SUMX(fact_sales, fact_sales[Quantity] * fact_sales[UnitPrice])— Better pattern: calculate Revenue column in Gold layer at load time
— then use SUM in the semantic model

The performance difference between a SUM and a SUMX is negligible on a 1,000-row table. On a 500 million-row Direct Lake fact table, a SUMX that row-iterates becomes a capacity issue. The DP-600 exam expects you to recognize when calculated columns should be built in the Gold transformation layer vs computed at query time in DAX. Move computation left — closer to data load time, not report render time.

Section 07

Capacity Guardrails — Row Limits, File Limits, and What Happens When You Exceed Them

Every F-SKU has Direct Lake guardrails. Exceeding them triggers forced fallback to DirectQuery regardless of DirectLakeBehavior setting. DP-600 expects you to know these limits and how to stay under them.

F-SKU	Max Rows per Table	Max Parquet Files	Memory	Recommended Use Case
F2–F16	~300M rows	~1,000 files	3–6 GB	Development, POC, small departmental models
F32	~600M rows	~2,500 files	12 GB	Small production models, pilot workloads
F64	~1.5B rows	~5,000 files	25 GB	Departmental fact tables. Minimum recommended for production Direct Lake.
F256	~6B rows	~8,000 files	100 GB	Large enterprise models — multi-year transaction history
F512	~12B rows	~10,000 files	200 GB	Enterprise-wide star schemas at scale
F1024	~24B rows	~10,000 files	400 GB	Global, petabyte-scale analytics models

Staying Under Guardrails in Production

Archive historical partitions: Move data older than your reporting window (e.g., 3 years) to archive tables. The semantic model Gold table only covers the active analytical period.
Run OPTIMIZE regularly: Consolidates small files from incremental loads into fewer, larger Parquet files. Keeps file count well below the F-SKU limit. Schedule after each pipeline run on high-volume tables.
Monitor file count before each load: If file count approaches the F-SKU limit, run OPTIMIZE before adding new data. Do not wait for the guardrail to be hit in production.
Partition by low-cardinality attribute: Partitioning by YearMonth keeps per-partition file counts low and makes archiving straightforward — drop an old partition rather than deleting rows.

Section 08

Monitoring Direct Lake Performance — DMV, Residency, and the Metrics App

Column Residency — Hot, Warm, Cold, SemiWarm

VertiPaq tracks whether column segments are in memory (Hot), partially loaded (Warm/SemiWarm), or on disk (Cold). Hot columns serve queries without storage I/O. Cold columns require segment reads from OneLake on each query — slower and more expensive at capacity scale.

DMV query — check column residency and dictionary sizes

— Run in DAX Studio against the semantic model
— Requires workspace admin or contributor roleSELECT
TABLE_NAME,
COLUMN_NAME,
RESIDENCY,         — Hot | Warm | SemiWarm | Cold
ROW_COUNT,
DICTIONARY_SIZE,
DATA_SIZE
FROM
$SYSTEM.INFO_STORAGETABLECOLUMNSEGMENTS
ORDER BY
RESIDENCY, DATA_SIZE DESC;

High-traffic columns — foreign keys, date keys, and frequently filtered attributes — should show Hot or Warm residency. If critical join keys are Cold, the model is reading from storage on every query. Fixes: increase capacity (more memory available for VertiPaq cache), reduce the column count in the model (fewer columns competing for cache), or partition more aggressively to reduce the data volume VertiPaq needs to frame.

Fabric Capacity Metrics App

The Capacity Metrics App shows Direct Lake framing operations as separate CU charges. A spike in framing CU consumption after a pipeline run indicates the semantic model is re-framing frequently — common when Automatic Updates is enabled during heavy ETL activity. Consider disabling Automatic Updates during large pipeline loads and triggering a single manual refresh when the load completes. For the complete Metrics App monitoring guide, see our Capacity Optimization Guide.

Automatic Updates — Enable vs Disable

Automatic Updates causes the Direct Lake semantic model to re-frame shortly after the underlying Delta tables change. For tables updated every few hours, this is efficient. For tables with continuous micro-batch updates (Eventstream or Mirroring with 30-second latency), Automatic Updates can cause dozens of framing operations per hour — each consuming CUs. Disable Automatic Updates on continuously updating tables and schedule a single refresh on a business-appropriate cadence instead.

Section 09

18 DP-600 Direct Lake Exam Questions — With Full Explanations

These questions mirror the scenario-based format of the DP-600 exam. Each question presents a situation and expects you to choose the correct technical response.

Q1 — When does Direct Lake via SQL endpoint automatically fall back to DirectQuery?

Direct Lake via SQL endpoint falls back when the SQL layer introduces features VertiPaq cannot respect natively: Row-Level Security defined in SQL, non-materialized views that require query rewriting, and tables that exceed F-SKU capacity guardrails. Direct Lake on OneLake bypasses the SQL layer entirely and eliminates the first two trigger categories.

Q2 — A team wants queries to fail visibly during UAT rather than fall back silently. Which DirectLakeBehavior setting do they need?

DirectLakeOnly. This setting returns an error instead of falling back to DirectQuery. Issues surface immediately during testing rather than hiding behind slow queries. It is the right choice when predictable SLAs and testing transparency are the priority over always returning data.

Q3 — A regulatory dashboard must show blank rather than potentially stale data during a security policy update. Which DirectLakeBehavior setting applies?

DirectLakeOrEmpty. This setting returns an empty result set on fallback instead of slow DirectQuery data or an error. It is the right choice when showing incorrect or stale data is more harmful than showing blank — a common requirement in regulated financial or healthcare reporting.

Q4 — A team sets DirectLakeBehavior to DirectLakeOnly but reports are still slow. What is the most likely cause?

The Direct Lake table exceeds the F-SKU row count or file count guardrail. Capacity guardrail breaches trigger forced fallback to DirectQuery even when DirectLakeBehavior is set to DirectLakeOnly. The behavior setting controls non-capacity fallback scenarios — it cannot override a capacity limit breach. Fix: upgrade the F-SKU, archive old partitions to reduce row count, or run OPTIMIZE to consolidate files and reduce file count.

Q5 — Why is V-Order compression critical for Direct Lake performance?

V-Order rearranges data inside Parquet files to optimize column-store compression. It improves dictionary encoding efficiency, reduces file sizes, and increases VertiPaq cache hit rates. For multi-billion-row fact tables in Direct Lake, V-Order reduces the memory footprint and means more data stays in Hot residency between queries — reducing storage reads per query.

Q6 — What is the recommended row group size for Direct Lake Delta tables and why?

1 million to 16 million rows per row group, targeting approximately 4 million. Too small: metadata overhead increases and VertiPaq must manage more segments. Too large: individual segments become expensive to cache and harder to prune. The 4M target balances compression efficiency, cache granularity, and segment elimination performance.

Q7 — A team uses Z-Order BY (CustomerKey, ProductKey) on their fact table. What does this achieve?

Z-Order co-locates rows with similar CustomerKey and ProductKey values in the same Parquet files. When a Power BI visual filters by customer or product, VertiPaq can identify and skip files that do not contain matching key values — predicate pushdown. This reduces the number of segments read per query and improves response times on filtered visuals.

Q8 — An F64 capacity hosts a Direct Lake model on a table with 1.8 billion rows. What will happen?

The table exceeds the F64 Direct Lake row count guardrail (~1.5 billion rows). Fabric will automatically fall back to DirectQuery for queries on this table. To fix: archive rows older than the active analytical period to reduce the row count below 1.5B, or upgrade to F256 (supports ~6B rows) or higher.

Q9 — Why does replacing CustomerName (VARCHAR) with CustomerKey (INT) improve Direct Lake performance?

Text columns create large dictionaries — every distinct string value must be stored and tracked by VertiPaq. Integer surrogate keys have dictionaries 10–100× smaller for equivalent cardinality. Smaller dictionaries mean: more columns fit in VertiPaq’s available memory, joins resolve faster, memory pressure on the semantic model decreases, and more segments stay in Hot or Warm residency between queries.

Q10 — A Direct Lake model shows many important columns in Cold residency via the DMV. What are the corrective actions?

Cold residency means segments are being read from OneLake storage rather than served from VertiPaq’s memory cache. Corrective actions: (1) Upgrade F-SKU to provide more available memory for VertiPaq; (2) Reduce the column count in the semantic model — remove unused columns that compete for cache; (3) Revise report usage patterns — cold columns are those that are queried infrequently enough that segments evict between queries; (4) Partition more aggressively to reduce the total data volume VertiPaq must frame.

Q11 — When is a hybrid table the correct DP-600 design recommendation?

A hybrid table is correct when the fact table is too large for Import but dimensions are small and security-sensitive. Load fact tables in Direct Lake for fast large-scale scans. Load dimensions in Import mode to support complex Row-Level Security, calculated columns, and user-friendly hierarchies without triggering Direct Lake fallback on the main fact. The DP-600 exam presents this when regulatory requirements mandate SQL RLS on dimensions but performance SLAs require Direct Lake speed on facts.

Q12 — How does Automatic Updates affect Direct Lake during heavy ETL activity?

Automatic Updates causes the semantic model to re-frame shortly after Delta files change. During heavy ETL with multiple pipeline runs or continuous Mirroring/Eventstream updates, this can trigger dozens of framing operations per hour — each consuming CUs from capacity. Recommendation: disable Automatic Updates on continuously updating tables and trigger a single manual refresh after the load pipeline completes. For daily batch loads, Automatic Updates is generally fine.

Q13 — A Direct Lake model is connected via SQL endpoint. Slow queries are traced to a non-materialized view. What is the fix?

Two options: (1) Replace the non-materialized view with a materialized view or a pre-calculated Delta table in the Gold layer, removing the fallback trigger; (2) Switch the semantic model connection from SQL endpoint to Direct Lake on OneLake — bypasses the SQL layer entirely, eliminating view-based fallback triggers. Option 1 is preferred when other systems also consume the SQL endpoint. Option 2 is preferred when the team controls the full Lakehouse design.

Q14 — Why should you target fewer than 200 Parquet files per partition?

Too many small files increase metadata overhead for both the Spark engine (during writes) and VertiPaq (during framing). Each file is a separate I/O operation during segment reads. Consolidating many small files into fewer, larger, well-compressed chunks reduces total I/O operations and speeds segment scanning. Run OPTIMIZE after incremental loads to consolidate files — particularly important for tables that receive frequent small micro-batch updates.

Q15 — A team migrates from Power BI Import mode to Direct Lake. What is the primary schema change required?

Direct Lake reads from Delta tables in OneLake. The semantic model must be reconfigured to point to Delta table sources rather than imported data sources. Practically: the Gold layer Lakehouse must contain the required tables as Delta format, the semantic model connection must switch from Power BI dataset to Lakehouse Direct Lake, and any Import-only features (complex calculated columns, certain RLS patterns) must be re-evaluated for compatibility with Direct Lake mode. DAX measures that work in Import generally work in Direct Lake — the primary concern is fallback triggers.

Q16 — When should you choose Direct Lake on OneLake over Direct Lake via SQL endpoint?

Choose OneLake when: (1) You can manage access control through OneLake item-level permissions rather than SQL RLS; (2) You need to support very large fact tables (approaching or exceeding F64 SQL endpoint limits); (3) Consistent sub-second performance is more important than SQL security feature support; (4) You want to eliminate an entire category of fallback triggers (SQL RLS and non-materialized views) by removing the SQL layer from the path.

Q17 — Why does the star schema model design still matter in Direct Lake environments?

Direct Lake improves how data is read from storage — it does not change how the semantic model is structured or how queries are evaluated by the formula engine. A poorly designed model (snowflaked dimensions, many-to-many relationships without bridge tables, calculated columns performing heavy row-by-row computation) underperforms in Direct Lake just as it does in Import mode. DP-600 rewards candidates who combine Direct Lake technical tuning with correct dimensional modeling: fact tables with integer surrogate keys, conformed dimensions, and date tables.

Q18 — An analytics engineer needs a Direct Lake model where exploratory queries must always return data, even if slower. Which setting applies, and why?

Automatic (default). Automatic allows graceful fallback to DirectQuery, so queries always return data — just potentially slower. This is the right choice for exploratory analytics environments where analysts prefer a slower correct answer over an error or blank result. The DP-600 exam uses “exploratory,” “must not interrupt user experience,” or “analysts prefer to always receive data” as the signal for Automatic behavior.

Section 10

FAQ – DP-600 Direct Lake Performance Optimization

What is Direct Lake in Microsoft Fabric?

Direct Lake is a Power BI storage mode in Microsoft Fabric that reads Delta-Parquet files directly from OneLake using the VertiPaq engine — without importing data and without per-query SQL overhead. It delivers near-Import query speed while always reading current Delta data. It is a core DP-600 exam topic under ‘Implement and manage semantic models’ and specifically ‘Optimize enterprise-scale semantic models.’

OneLake: VertiPaq reads Delta files directly — no SQL layer, zero SQL-based fallback risk. SQL endpoint: SQL analytics endpoint sits between VertiPaq and Delta files — introduces fallback triggers for SQL RLS and non-materialized views. Use OneLake when you can manage security at item level. Use SQL endpoint when SQL RLS or complex view logic cannot be removed.

What are the three DirectLakeBehavior settings?

Automatic (default) — allows graceful fallback to DirectQuery silently. Use for exploratory analytics. DirectLakeOnly — returns an error on fallback. Use for production with strict SLAs where issues must surface during testing. DirectLakeOrEmpty — returns empty result on fallback. Use when showing incorrect data is worse than showing blank (regulatory dashboards).

What causes Direct Lake to fall back to DirectQuery?

Six triggers: (1) SQL RLS defined in SQL endpoint; (2) Non-materialized views via SQL endpoint; (3) Row count exceeds F-SKU limit; (4) Parquet file count exceeds F-SKU limit; (5) Unsupported column data types; (6) Query features VertiPaq cannot process natively. Capacity guardrail breaches (3 and 4) cause forced fallback even when DirectLakeBehavior is set to DirectLakeOnly.

What Direct Lake topics are on the DP-600 exam?

Per the official DP-600 skills measured document updated April 20, 2026: Configure Direct Lake including default fallback and refresh behavior; Choose between Direct Lake on OneLake and Direct Lake on SQL endpoints; Implement performance improvements in queries and report visuals; Improve DAX performance. These appear under Optimize enterprise-scale semantic models within the Implement and manage semantic models domain (25–30% of the exam).

Section 11

Official References and Related UIG Guides

Official Microsoft Documentation

📋

DP-600 Official Study Guide — Skills Measuredlearn.microsoft.com · Current skills including Direct Lake domains — updated April 20, 2026

📖

Direct Lake Overview — Microsoft Learnlearn.microsoft.com · Architecture, framing, fallback, OneLake vs SQL endpoint

⚡

Understand Direct Lake Query Performance — Microsoft Learnlearn.microsoft.com · Residency states, guardrails, row group sizing, DMV monitoring

🎓

DP-600 Exam Page — Microsoft Learnlearn.microsoft.com · Scheduling, free practice assessment, renewal

Related UIG Data Lab Guides

🔧

Direct Lake Fallback to DirectQuery — Diagnosis & Fixultimateinfoguide.com · Step-by-step diagnosis and resolution for production fallback

🏗️

Fabric Lakehouse Tutorialultimateinfoguide.com · Build the Gold Lakehouse your Direct Lake semantic model reads

🏛️

Data Warehousing in Microsoft Fabricultimateinfoguide.com · Gold Warehouse as Direct Lake source — T-SQL and Direct Lake mode

📈

Fabric Data Warehouse Optimizationultimateinfoguide.com · Query performance, statistics, partitioning for warehouse-backed Direct Lake

⚡

Microsoft Fabric Capacity Optimizationultimateinfoguide.com · Monitor Direct Lake framing CU cost via Capacity Metrics App

🏅

Medallion Architecture in Microsoft Fabricultimateinfoguide.com · Build the Bronze → Silver → Gold pipeline Direct Lake reads from

🔄

Power BI Premium to Fabric Migrationultimateinfoguide.com · Migrate existing Import semantic models to Direct Lake

🎓

DP-700 Exam Guide — Fabric Data Engineerultimateinfoguide.com · The data engineering certification that pairs with DP-600

🎯

Power BI Interview Questionsultimateinfoguide.com · Direct Lake interview Q&A for DP-600 candidates

⚠️ Accuracy Disclaimer

All exam domain percentages and skill topics are sourced from the official DP-600 skills measured document (updated April 20, 2026). Capacity guardrail figures are sourced from Microsoft Learn — Understand Direct Lake query performance. Microsoft updates exam content and capacity limits periodically — verify current values before your exam date. UIG Data Lab is an independent publication, not affiliated with or endorsed by Microsoft Corporation.

A.J. Data Engineering Researcher & Technical Writer · UIG Data Lab All articles →

A.J. researches and writes about data engineering, analytics architecture, Microsoft Fabric, and modern cloud data platforms. Coverage spans Microsoft Fabric, Power BI, Azure Data Engineering, Databricks, Snowflake, Apache Spark, dbt, Apache Airflow, and modern cloud data infrastructure. The focus is practitioner-level content that helps data professionals understand platform capabilities, evaluate technology decisions, optimize costs, and implement practical solutions using official documentation, product updates, community insights, and industry best practices. His writing covers real decisions from real deployments — not documentation rewrites.

DP-600 Direct Lake Microsoft Fabric Power BI DAX Semantic Models OneLake V-Order Delta Lake