Why Do Direct Lake Reports Fail on F32 Capacity?
Optimize performance
Identify and resolve errors
Answer
Correct answer: B — Increase the capacity so the 500 million-row fact table in DW1 fits within Direct Lake limits and stops falling back.
You have a Fabric F32 capacity that contains a workspace. The workspace contains a warehouse named DW1 that is modelled by using MD5 hash surrogate keys. DW1 contains a single fact table that has grown from 200 million rows to 500 million rows during the past year. You have Microsoft Power BI reports that are based on Direct Lake. The reports show year-over-year values. Users report that the performance of some of the reports has degraded over time and some visuals show errors. You need to resolve the performance issues. The solution must meet the following requirements: Provide the best query performance. Minimize operational costs. Which should you do?
Community Insight
The question tests Direct Lake SKU row-limit thresholds, and the common trap is tuning keys, views, or V-Order instead of recognizing that 500 million rows exceeds the F32 table limit and forces fallback.
This DP-700 question tests the Direct Lake per-table row limits tied to Microsoft Fabric capacity SKUs and why a 500 million-row fact table on F32 causes degraded report performance and visual errors. The correct resolution is to increase the capacity so the table again fits within Direct Lake limits and stops falling back to slower query modes.
Option D (change surrogate key data type) is the most-chosen wrong answer: integer keys improve join efficiency but do not reduce the 500 million row count, so the table still breaches the F32 Direct Lake limit and continues to fall back.
Community Discussion (98 comments)
yk2085
👍 1
Selected: C
I will opt in for Enable V-Order
alqazqzy.asseel
👍 1
Selected: D
MD5 hash string length is 32 characters hexadecimal, so when the table grows to 500 million rows, the memory footprint exceeded the F32 capcity guardrail and that will force Power BI reports to fall back to direct query mode. The solution is to use another data type such as numeric data type instead of MD5 hash
Ce____
👍 1
Selected: C
Given the Operational Cost for the Increase in Capacity, I will opt in for Enable V-Order
priya_rastogi
👍 1
Selected: D
The fact table has grown to 500 million rows, and it uses MD5 hash surrogate keys. Hash keys are typically large string/binary values, which increase storage and memory usage and can hurt Direct Lake query performance.
Bs2009
👍 3
Selected: B
Microsoft currently documents an F32 guardrail of 300 million rows per table. "https://learn.microsoft.com/is-is/fabric/fundamentals/direct-lake-overview", V-Order can improve Direct Lake scan/compression performance but does not solve the F32 300-million-row guardrail
AmirAhmadabadi
👍 2
Selected: D
MD5 produces a 32-character hexadecimal string (128-bit value). For a fact table with 500 million rows, using string-based MD5 keys causes: Larger storage footprint Higher memory consumption Slower joins between fact and dimension tables Reduced Direct Lake performance Direct Lake performs best when using: Integer surrogate keys (BIGINT, INT) Narrow columns Efficient joins Replacing MD5 hash keys with numeric surrogate keys significantly reduces: Storage Scan time Memory usage This improves query performance without increasing capacity costs. Since the requirement includes minimizing operational costs, optimizing the model is better than buying more capacity. Meets performance requirement Meets cost requirement
guy3hil
👍 1
Selected: C
Justification 1. Performance Needs The warehouse DW1 has grown significantly (200M → 500M rows). Reports use Direct Lake, which queries data directly from the lake without import. As data volume increases, query scans become heavier. V‑Order optimizes the physical layout of columnar data (Delta tables) by re‑ordering and compressing it, which reduces I/O and speeds up scans. This directly improves query performance for Power BI visuals. 2. Cost Considerations Increasing capacity (Option B) would improve performance but at a higher operational cost (more compute units). V‑Order achieves performance gains without increasing compute costs, making it the cost‑efficient solution.
kzaki
👍 1
Selected: C
v-order targets query performance
juamd
👍 1
Selected: D
MD5 hash keys are stored as wide string/binary types (16–32 bytes), which are inefficient in Direct Lake. As the fact table grew to 500M rows, these keys trigger DirectQuery fallback, causing slow performance and visual errors. Converting surrogate keys to BIGINT keeps queries within Direct Lake guardrails, enables better compression, and speeds up joins — meeting both performance and cost requirements. The other options either worsen the problem (A), increase costs (B), or don't address the root cause (C, E).
ChandrajitS
👍 1
Selected: B
The existing capacity limitation reached 300 million rows for F32.
32950cb
👍 2
Selected: D
The root cause of the performance degradation is the use of MD5 hash surrogate keys. MD5 hashes are typically stored as 32-character strings or binary values, which create several problems for Direct Lake and the VertiPaq engine as the table grows
cd93
👍 2
Selected: B
4,500$/month for F32 capacity, and get a Direct Lake limit of only 300 million rows table... 300 million table is actually pretty tiny even for a middle-sized company This is too costly... onprem Postgres can handle this amount just fine
Josekonoor
👍 1
Selected: C
increase capacity
Josekonoor
👍 1
Selected: B
Fabric F32 capacity fact table that has grown from 200 million rows to 500 million rows -> increase capacity
Mustafa_Shazly
👍 1
Selected: B
after trying I found for warehouse not lakehouse - V order enabled by default on all warehouses. - It cannot be enabled/disabled for individual tables. - You can disable but can't re-enable again. And on the other hand F32 can handle up to 300 M rows so I think B is true
e0f0ce6
👍 1
Selected: C
I think it's C. Sure Capacity increase gives more performance. V-order does increase performance as well but at lower costs.
chandu_3812
👍 1
Selected: C
Enable V-Order
KTechLeg
👍 1
Selected: C
V-order is for gold delta tables optimizing them in a way that Power BI (especially NRT) read it better and faster.
Mustafa_Shazly
👍 1
Selected: B
I change my anser from D to B becuase F32 has limit 300M Rows https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-guardrails
Mustafa_Shazly
👍 3
Selected: D
I think D is true Problem is performance issues because increase in data mean memory lake - MD5 and SHA256 Take a lot of memory so SHA256 will raise the problem -V order used to speed up not solve errors - increase cap true but we have condition (min ops cost)
TomGray1989
👍 1
Selected: C
The thing is, increasing capacity is a potential solution here - but it's really not the first solution to jump to. Yes you'll get more compute power accessibility to potentially resolve performance issue but the cost is significant. Enable V-Order must be the 1st step (provide best query performance whilst keeping cost under control.) I think this question is testing your ability to prioritise solution testing. Enabling V Order may resolve your issue quickly, it won't increase your costs. Increasing Capacity may resolve your issue quickly, but it actually maximises operational cost. The answer here is C
dantat
👍 2
Selected: B
F32 has a limitation of 300 millions Rows per table https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements
a10
👍 2
Selected: B
Consider row limits
Anand_20061987
👍 4
Selected: D
The best answer is D – modify the surrogate keys to use a different data type. Using MD5 hash keys (large 16–32 byte values) causes memory and performance issues as the fact table grows. Switching to integer (INT/BIGINT) surrogate keys reduces memory usage, speeds up joins, and improves storage efficiency. Other options (like SHA256, increasing capacity, or using views) don’t fix the root problem — the inefficient data type. Integer keys are the best practice for performance and scalability.
toure1
👍 1
Et qu'en est-il de la limite à 300 millions de la capacité F32?
Patrikkhalaf
👍 3
Selected: C
B. Increase the capacity Would improve performance but increases costs, violating the requirement to minimize operational costs. C. Enable V-Order V-Order is an optimization in Fabric Warehouses/Lakehouses that orders data column-wise for better compression and query performance. Specifically designed to boost Direct Lake performance. Cost-neutral (storage optimization, not compute scaling). Best fit here.
certs4pk
👍 1
even after enabling v-order, it still falls back 2direct query mode, coz capacity guardrails were exceeded.. hence leaning towards 'expanding capacity' option
d0bdf05
👍 2
Selected: C
Enable V-Order: reshape parquet files (optimizing its). So, performance should be better, with option B (increase capacity) we have more costs which is one of the question requirement.
raweb
👍 1
Selected: B
F2 <> F3 300 milions row.... Increase capacity is needed
8115575
👍 2
Selected: B
An F32 SKU in Microsoft Fabric has a limit of 10 GB of memory per semantic model and can handle 300 million Direct Lake rows per table
jakkuc92
👍 4
Selected: B
F32 supports: 300 million rows per table 40 GB model size on disk 10 GB max memory Your fact table has 500 million rows, which exceeds the supported limit for F32 in Direct Lake mode. This mismatch can cause: Visual errors Slow performance Query failures or memory overflows 🧠 Summary: If you're using Direct Lake and your table exceeds the row or memory limits of your SKU, increasing capacity is necessary to ensure stability and performance. V-Order is still a great optimization, but it won’t help if you’re over the SKU limits. ✅ Final Answer: B. Increase the capacity
127fe02
👍 1
Selected: C
Bullshit question, the V-Order is turn-on by default. But the question still ask about this :(
hergoi
👍 2
Selected: C
On a table with 500 million rows covering data from multiple years, the main cost is not the JOIN operation but scanning the huge fact table for the relevant dates — so V-Order will make more sense than changing the primary key from MD5 to SHA256.
be79ac3
👍 2
Selected: C
With it saying minimize costs I thought it had to be C.
medeirosLF
👍 1
Selected: B
B is the correct answer. V-order is enabled by default; if you disable it, you can't turn it enable again.
medeirosLF
👍 1
Selected: B
V-order is enabled by default.
necktru
👍 1
Selected: B
Vorder cant be enabled
ba2bfdf
👍 1
Selected: B
Direct Lake mode limit 300 Mill. Fallback option mode switch to Direct Query which degrade the performance. Hence Capacity had to be increased.
Shw7
👍 1
Selected: C
Min operational Cost = Enable V Order
VenkataPhaniPavanKumar
👍 1
Selected: C
Why Other Options Are Unsuitable: Option: A (Change MD5→SHA256) Reason for Exclusion: Increases key size (128→256 bits), worsening storage/join performance. Option:B (Increase capacity) Reason for Exclusion:Raises costs (contradicts "minimize operational costs"). Option:D (Modify surrogate keys) Reason for Exclusion: Requires rebuilding the entire data model (high effort/cost). Option:E (Create views) Reason for Exclusion: Adds abstraction without optimizing underlying data scans.
VenkataPhaniPavanKumar
👍 1
Selected: C
The best option to address performance degradation while minimizing operational costs is C. Enable V-Order. Here’s why: V-Order is a storage format optimization for Delta Lake tables (used by Direct Lake mode in Power BI). It improves data skipping, which enables faster query performance by reducing the amount of data scanned. Especially with large fact tables like yours (500 million rows), enabling V-Order can have a significant impact on performance without increasing costs. It’s a low-cost, high-impact optimization since it doesn’t require more compute resources (unlike increasing capacity). Why not Improve Capacity? Effective, but it increases costs. Only do this if V-Order and other optimizations don’t solve the problem.
ogbenisho
👍 1
Selected: C
V-Order is a write-time optimization for Parquet files in Microsoft Fabric that significantly enhances read performance within Fabric compute engines like Power BI, SQL, and Spark. It achieves this by applying special sorting, row group distribution, dictionary encoding, and compression to the Parquet files. This optimization is crucial for Fabric's Direct Lake mode, which relies on V-Order for efficient data access
Ariel_Subia
👍 1
Selected: B
Increase the capacity is correct for me.
Wipag
👍 1
Selected: C
V-Order is a performance optimization feature for Delta tables in Fabric. It reorders data for faster analytical queries by optimizing columnar layout and file structure. Improves read performance in Direct Lake mode dramatically without extra cost. No need to reload or refactor the data, so minimal operational impact.
DaniMb91
👍 1
Selected: B
300 million rows is not a hard limit, but rather a performance recommendation for optimal operation under Direct Lake with F32 capacity. Your table has 500 million rows, which exceeds this recommended limit by 66% — a likely contributor to performance issues.
smanzana
👍 1
Selected: C
The correct is C
Shw7
👍 2
Selected: D
. Modify the surrogate keys to use a different data type.
pramod4lk
👍 1
Selected: C
Rather than buying more capacity or overhauling your surrogate-key design, simply enable V‑Order clustering on your most selective columns.
HI1612
👍 1
Selected: C
Enabling V-Order in Microsoft Fabric (specifically for Direct Lake datasets) changes how data is physically stored and accessed, optimizing both read and write operations.
lord_mufi
👍 1
Selected: B
F32 tenant capacity has 300 million rows maximum consumption. The scenario has exhausted the capacity. You must increase the capacity to rectify the problem. Enable V-Order is actived by default except disabled. SHA5 has high byte encryption size which will even the performance. The last option trigger the connection mode to DirectQuery which is even worst. Option B is the answer
Stef6108
👍 2
Selected: B
Direct lake row limit per table is 300 million in an F32 capacity => Fallback to Direct Query
malik777
👍 1
Selected: C
Improves query performance by optimizing how data is stored and accessed.
Madhu2023
👍 1
Selected: B
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fallback
Tuki93
👍 21
Selected: B
After reviewing the public documentation again, I understand that V-Order is enabled by default in Data Warehouses, as the documentation only refers to how it can be disabled—and notes that this action is irreversible. https://learn.microsoft.com/en-us/fabric/data-warehouse/v-order#scenarios-where-v-order-might-not-be-beneficial At the same time, I agree with my peers who mentioned that the row limit per table is 300 million in an F32 capacity. Therefore, I’m updating my answer to option B: Increase the capacity. https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements
ANayakOdisha
👍 1
Selected: C
Enabling V-Order (Vectorized Order-Preserving Encryption for Data Lakes) can significantly improve query performance for analytics workloads, especially in scenarios where you have large datasets like in your case with 500 million rows. V-Order helps optimize query processing and can enhance the efficiency of operations like year-over-year comparisons, which are common in Power BI reports. This optimization can lead to better performance without the need for costly infrastructure upgrades, aligning with the goal of minimizing operational costs.
MP035
👍 1
Selected: B
V-order is enabled by default for warehouse. so Increase capacity to support higher record is the correct answer
turlakDE
👍 1
Selected: B
F32 and limit on the rows - 300M
DarioReymago
👍 2
Selected: B
Option B direct Lake limitation by sku (fallback) https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements
yue_young
👍 1
Selected: E
Obviously the answer should be C and E(if there are two answers). Surely to increase the capacity could help improve the performance, but it also demands more money. Considering the report only shows the value year-over-year, to create a more coarse-grained data view would be best.
SebGo
👍 1
Selected: B
Because of Row Limitation
oose
👍 1
Selected: C
Enable V order should be the first step
upliftinghut
👍 1
Selected: B
V-Order is enabled by default. F32 has max number of rows of 300M per table: https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview
ZZIN
👍 1
Selected: C
Surely you are confused between answer B and C. Since it is stated to minimize operational costs, isn't C the correct answer?
reemprive
👍 1
Selected: B
You can't enable V-Order. It's enabled by default. You can disable V-Order, but you can't turn it back on.
mDp0r
👍 1
Selected: B
Agree to the 300kk row limit on direct lake for an f32
easihene
👍 1
Selected: C
The documentation (https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview) confirms that the row-count guardrail of an F32 capacity (300 million rows per table) is now being breached by your 500-million-row fact table, and that exceeding a guardrail pushes Direct Lake queries into DirectQuery fallback, which is exactly what users are experiencing as “slow visuals” and intermittent errors. Because the only reliable way to lift that guardrail is to move to the next SKU, the best fix is to scale the capacity to F64 (or higher), where the limit rises to 1.5 billion rows per table. This leaves plenty of headroom and restores Direct Lake performance without any refactoring.
easihene
👍 1
Admin, please note: I met to select B and not C.
AnetaK
👍 3
Selected: E
As a PBI developer I would prefer to have views created. Visuals show error because there is two much data to be calculated. I would prefer to have less data, so the granular data should be aggregated, we need only yearly data. Then there would be less data to be calculated in the visual query.
CloudKaKida
👍 1
Selected: B
https://learn.microsoft.com/en-us/fabric/real-time-intelligence/event-streams/process-events-using-event-processor-editor?pivots=enhanced-capabilities Fabric SKU Parquet files per table Row groups per table Rows per table (millions) Max model size on disk/OneLake (GB) Max memory (GB) 1 F2 1,000 1,000 300 10 3 F4 1,000 1,000 300 10 3 F8 1,000 1,000 300 10 3 F16 1,000 1,000 300 20 5 F32 1,000 1,000 300 40 10 F64/FT1/P1 5,000 5,000 1,500 Unlimited 25 F128/P2 5,000 5,000 3,000 Unlimited 50 F256/P3 5,000 5,000 6,000 Unlimited 100 F512/P4 10,000 10,000 12,000 Unlimited 200 F1024/P5 10,000 10,000 24,000 Unlimited 400 F2048 10,000 10,000 24,000 Unlimited 400
el_massakre
👍 3
Selected: B
Raise the capacity so Fabric can use DireqtQuery without fallback. https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fallback
yourock43mfamily
👍 1
Selected: C
V-order improves read performance
SameerL
👍 1
Selected: C
The best option is: C. Enable V-Order. Explanation: Best Query Performance: V-Order is an optimization feature in Fabric that improves query performance by organizing Parquet files more efficiently. It enhances compression, speeds up scan performance, and reduces I/O, making it ideal for large datasets like your 500 million-row fact table. Minimize Operational Costs: Enabling V-Order does not require scaling up capacity, unlike option B (Increasing the capacity), which adds costs. It optimizes storage and query performance without additional compute resources.
kumarzzz
👍 1
Selected: D
My suggestion to be both things To minimize operational costs, you can modify surrogate keys by using a smaller integer data type (e.g., INT instead of BIGINT) and enabling V-order (Virtual Order) for faster data retrieval, if applicable.
MultiCloudIronMan
👍 3
Selected: C
Changing the surrogate key data type would likely involve significant re-engineering efforts without guaranteeing a performance improvement.
zxc01
👍 1
V-Order in fabric warehouse is enabled by default, and you cannot disable it.
Sher_Lock_Alexa
👍 2
Selected: C
V-Order is a highly optimized columnar storage format in Microsoft Fabric that compresses and accelerates queries
hebertorosillo
👍 2
Selected: D
B. Minimize operational costs is false. A. Distraction. C. Warehouse is not possible in this sentence. V-Order is configured in a notebook because it is incorrect. D. It is true because https://learn.microsoft.com/en-us/fabric/data-engineering/delta-optimization-and-v-order?tabs=sparksqlit reduces and increments performance by utilizing minimal operational costs.
dazero
👍 30
Selected: B
500 million rows is over the F32 table limit.
el_massakre
👍 4
He's right. When its over the limit the query performance gets reduces by the fallback. https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fallback
satyaammm
👍 1
Only when you are saving in optimized format .. otherwise its not enabled by default.
ChenFu
👍 2
Selected: C
V-Order is a storage optimization format used in Microsoft Fabric for Delta tables. It organizes data in a highly compressed and sorted format, improving query performance while reducing storage costs. Since your reports are based on Direct Lake, enabling V-Order will directly enhance read performance without increasing operational costs. Increasing capacity (B) would add cost, while changing hash keys (A) or modifying data types (D) are more complex and don't guarantee significant performance gains. Creating views (E) does not optimize the underlying storage and, therefore, won't address the root cause effectively.
henryphchan
👍 2
Selected: D
V-Ordering is enabled by default in Fabric Datawarehouse. I have created a new datawarehouse and verify the default v-order status: SELECT [name], [is_vorder_enabled] FROM sys.databases; Disabling V-Order is irreversible: once disabled, it cannot be enabled again. So C is not a valid option. https://learn.microsoft.com/en-us/fabric/data-warehouse/v-order
clux
👍 1
Selected: C
V-Order improves read performance by applying special optimizations such as sorting, row group distribution, dictionary encoding, and compression on Parquet files. This enhances query performance significantly, especially for large datasets. Additionally, V-Order is cost-effective as it reduces the amount of resources needed for reading data, leading to improved performance without increasing operational costs.
prabhjot
👍 1
Selected: C
i think the answer should be V-order since it will sort data before writing and hence give you better read performance without increasing the capacity which also optimizes on operational costs!
dazero
👍 8
V-order is enabled by default.
h2o_molecule
👍 1
Selected: C
V-Order is a columnar storage format that optimizes data storage and retrieval. It can significantly improve query performance and reduce storage costs by compressing data and minimizing the amount of data read during queries. This makes it a suitable choice for large fact tables and scenarios where you need to improve performance without increasing operational costs.
robertlavigne
👍 7
Selected: B
B. Although B is expensive I think it is the only viable option. https://learn.microsoft.com/en-us/fabric/get-started/direct-lake-overview See the table on Directlake limitations in the above link. For F32 it is 300 million rows before direct query fallback occurs. For F64 it is 1500 million rows. V Order or Key modification don't minimize the row count and won't avoid these limitations. Views aren't supported in DirectLake and will always fallback to direct query so thats not helpful.
i_have_a_name
👍 3
Selected: D
SHA26 generates a 64 character length key, which will affect the performance further. V-Order is enabled by default in Fabric. Modifying the surrogate key should be the cost effective solution.
mixonfreddy
👍 4
Selected: D
You have to modify the surrogate keys
manolet
👍 2
Selected: C
Changing surrogate keys is not a straightforward solution. The key is that you need to make the decision based on minimizing operational cost.
h2o_molecule
👍 2
is V-order automatically enabled on warehouse? No, V-Order is not automatically enabled on a warehouse. You would need to enable it manually to take advantage of its benefits for improved query performance and data compression.
Raibeth
👍 3
I still have the same doubt.
QAZdbarhate12345678
👍 4
Selected: D
The best solution to resolve the performance issues while meeting the requirements of best query performance and minimizing operational costs is: D. Modify the surrogate keys to use a different data type.
Tuki93
👍 32
Selected: C
Enable V-Order: This should be your first step as it directly targets performance improvements with minimal cost. Consider the following before deciding to disable V-Order: Microsoft Fabric Direct Lake mode depends on V-Order. https://learn.microsoft.com/en-us/fabric/data-warehouse/v-order#performance-considerations
AzurePart
👍 2
Did you read the contents of the url document you wrote? https://learn.microsoft.com/en-us/fabric/data-warehouse/v-order#performance-considerations "Currently, disabling V-Order can only be done at the warehouse level, and it is irreversible: once disabled, it cannot be enabled again. Users must consider the performance if they choose to Disable V-Order in Fabric Warehouse."
Adriel_1996
👍 6
What about the limit on the rows limitation (https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview) ?
GHill1982
👍 4
Would V-Order not already be enabled by default?
IshtarSQL
👍 8
Selected: D
While MD5 hashes are deterministic and ensure uniqueness, they can be less efficient for join operations compared to integer-based keys. This inefficiency arises because joining on lengthy string keys demands more computational resources than joining on shorter, integer-based keys. Recommendation: Modify the surrogate keys to use a different data type, specifically integers.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
On Direct Lake, each capacity SKU enforces a maximum rows-per-table threshold — F32 supports 300 million rows per table, while F64 raises that to 1.5 billion. DW1's fact table has grown to 500 million rows, so on F32 the model exceeds the supported limit and the engine drops into DirectQuery fallback, which is exactly what the users see as degraded performance and visual errors. Increasing the capacity moves the table back within the Direct Lake limit, restoring in-memory Parquet-based query performance, which satisfies the best query performance requirement. It is also the only option that eliminates the root cause rather than masking it, keeping operational effort minimal. Community members such as dazero, robertlavigne, and jakkuc92 all correctly identified the 300 million row F32 threshold as the deciding factor.Why the Other Options Are Wrong
Option A (SHA256) makes hash values wider than MD5 and does nothing to reduce row count, so it cannot remove the SKU limit and may even increase storage. Option C (V-Order) is already enabled by default in Fabric warehouses and is irreversible to disable, so enabling it changes nothing; as Tuki93 later acknowledged, the documentation only describes how to turn it off. Option D (change surrogate key data type) helps join efficiency but, as robertlavigne noted, key modificationOfficial Reference
Exam Strategy
Always check the Direct Lake per-SKU limits (rows per table, model size, memory) before considering tuning options; when a table exceeds the F32 threshold the only fix is a SKU increase. Treat V-Order and key-type changes as secondary optimizations that cannot bypass a capacity limit.
Frequently Asked Questions
Why doesn't changing the MD5 surrogate keys to integers fix the report errors?
Integer keys improve join speed, but they do not lower the 500 million row count, so the table still exceeds the F32 Direct Lake limit and keeps falling back to DirectQuery.
Isn't V-Order already enabled and therefore not a solution?
Yes. V-Order is enabled by default for Fabric warehouses and can only be disabled, not newly enabled, so option C changes nothing about the current performance.