Why Do Direct Lake Reports Fail on F32 Capacity?

DP-700 By islever Editorial Last updated

Optimize performance Identify and resolve errors

Short answer

B Increase the capacity so the 500 million-row fact table in DW1 fits within Direct Lake limits and stops falling back.

Question

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?
  1. Change the MD5 hash to SHA256.
  2. Increase the capacity. Correct Answer
  3. Enable V-Order.
  4. Modify the surrogate keys to use a different data type.
  5. Create views.

Key Takeaways

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.

Common mistake: 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.

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 modification

Official Reference

These links open the official vendor documentation in a new tab.

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.

More DP-700 FAQ →

Discussion 97 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 97

  1. Tuki93 👍 32 Answered 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
  2. dazero 👍 30 Answered B
    500 million rows is over the F32 table limit.
  3. Tuki93 👍 21 Answered 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
  4. IshtarSQL 👍 8 Answered 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.
  5. robertlavigne 👍 7 Answered 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.
Show 25 more comments
  1. Adriel_1996 👍 6
    What about the limit on the rows limitation (https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview) ?
  2. jakkuc92 👍 4 Answered 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
  3. Anand_20061987 👍 4 Answered 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.
  4. QAZdbarhate12345678 👍 4 Answered 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.
  5. 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
  6. GHill1982 👍 4
    Would V-Order not already be enabled by default?
  7. mixonfreddy 👍 4 Answered D
    You have to modify the surrogate keys
  8. Patrikkhalaf 👍 3 Answered 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.
  9. AnetaK 👍 3 Answered 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.
  10. Bs2009 👍 3 Answered 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
  11. Mustafa_Shazly 👍 3 Answered 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)
  12. i_have_a_name 👍 3 Answered 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.
  13. el_massakre 👍 3 Answered B
    Raise the capacity so Fabric can use DireqtQuery without fallback. https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fallback
  14. MultiCloudIronMan 👍 3 Answered C
    Changing the surrogate key data type would likely involve significant re-engineering efforts without guaranteeing a performance improvement.
  15. Raibeth 👍 3
    I still have the same doubt.
  16. AmirAhmadabadi 👍 2 Answered 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
  17. ChenFu 👍 2 Answered 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.
  18. 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."
  19. hebertorosillo 👍 2 Answered 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.
  20. henryphchan 👍 2 Answered 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
  21. 32950cb 👍 2 Answered 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
  22. hergoi 👍 2 Answered 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.
  23. cd93 👍 2 Answered 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
  24. 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.
  25. d0bdf05 👍 2 Answered 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.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

A 500-million-row fact table exceeds the F32 Direct Lake guardrail, so increase the capacity to F64

S-grade

Shortcut caching supports only S3/GCS shortcuts and excludes files larger than 1 GB

S-grade

Updating warehouse tables requires at least the Contributor workspace role because Write is not shareable to a Viewer

S-grade

Run T-SQL in a KQL database only by prefixing the query with a -- comment line

S-grade

← Back to DP-700 Study Guide