A 500-million-row fact table exceeds the F32 Direct Lake guardrail, so increase the capacity to F64
Optimize performance
Answer
Correct answer: B - 500M rows exceed the F32 Direct Lake guardrail of 300 million rows per table, forcing DirectQuery fallback; F64 (1,500M rows) restores Direct Lake performance.
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 Votes
42% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Direct Lake table guardrails scale with the SKU: F32 allows 300 million rows per table while F64 allows 1,500 million; exceeding the guardrail triggers DirectQuery fallback, which is exactly what degraded the year-over-year Direct Lake reports.
DW1's fact table grew to 500 million rows, above the F32 Direct Lake guardrail of 300 million rows per table, so Direct Lake falls back to DirectQuery and the Direct Lake reports degrade with visual errors. Increasing the capacity to F64, which allows 1,500 million rows per table, keeps the table in Direct Lake for the best query performance.
Choosing V-Order or a surrogate key change, neither of which addresses the row-count guardrail: V-Order is already enabled by default in Fabric, and changing the key data type does not reduce the table's row count.
Community Discussion (19 comments)
Tuki93
👍 13
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
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.
abdulbasit170
👍 1
Selected: C
V-order reordering only optimize the queries based on one or two colunns, and Fabric choose those columns under the hood. Unlike Z-order of data bricks. So it does not optimize the queries on all columns, but mostly does the job. Still the best answer by keeping the cost low.
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
👍 2
Selected: C
Changing the surrogate key data type would likely involve significant re-engineering efforts without guaranteeing a performance improvement.
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
👍 7
Selected: B
500 million rows is over the F32 table limit.
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!
robertlavigne
👍 6
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.
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.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.