Resolving Direct Lake Row Limits in Fabric F32 Capacity

DP-700 By islever Editorial Last updated

Optimize performance Identify and resolve errors

Short answer

A Create views to logically partition or filter the 500M row fact table, ensuring queries stay within the F32 Direct Lake 300M row limit and minimizing costs compared to scaling capacity.

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

Key Takeaways

The trap is focusing on data type optimization (B) or capacity scaling (D); the real issue is the 300M row hard limit for Direct Lake on F-series, which requires logical partitioning via views.

Learn how to resolve Direct Lake performance errors and row limit violations in Microsoft Fabric F32 capacity by using views to optimize data access patterns.

Common mistake: Many users select Option D (Increase capacity) because it seems like a direct fix, but it violates the 'minimize costs' requirement. Others choose B (Modify data types), which helps storage but doesn't bypass the hard row count limit causing the Direct Lake failure.

Expert Analysis

The core constraint in this scenario is the F32 capacity combined with a Direct Lake semantic model. According to Microsoft Fabric documentation, F-series capacities (specifically F2 through F64) impose a hard limit of 300 million rows per table for Direct Lake mode. If a table exceeds this row count, the query engine cannot serve it via Direct Lake and typically falls back to DirectQuery or fails entirely, leading to the reported performance degradation and visual errors.

While comments suggest modifying data types (Option B) to improve efficiency, this does not resolve the fundamental architectural violation of the row limit. Changing an MD5 hash to a BIGINT reduces storage size but does not reduce the row count; the table remains at 500 million rows, which still exceeds the F32 Direct Lake threshold. Similarly, increasing capacity (Option D) would solve the problem, but the requirement to "minimize operational costs" makes scaling up expensive infrastructure less optimal than optimizing the schema if possible. However, since the row limit is a hard ceiling for F-series Direct Lake, simply changing data types won't fix the error.

The most effective way to resolve the performance issues and errors while keeping costs low on an F32 capacity is to reduce the number of rows processed per query. Creating views (Option A) allows you to partition or filter the data logically without moving it. By creating views that aggregate or filter data (e.g., by year, as mentioned in the context of "year-over-year values"), you can ensure that queries only access subsets of the data that fit within the memory and row limits of the F32 capacity. This avoids the need for expensive capacity upgrades (D) and works within the existing storage constraints. It provides the best query performance by reducing I/O and memory pressure, directly addressing the root cause of the Direct Lake fallback/errors.

Official Reference

https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements

This link opens the official vendor documentation in a new tab.

Exam Strategy

When facing performance issues in Fabric Direct Lake, always check the capacity tier's specific row limits first. For F-series, the 300M row limit is a critical bottleneck. If your data exceeds this, look for schema optimizations like views or partitions that keep query payloads under the limit before considering expensive capacity upgrades.

Frequently Asked Questions

Why doesn't changing the surrogate key data type fix the error?

Changing the data type from string to integer reduces storage size but does not reduce the row count. Since the error is caused by exceeding the 300M row limit for Direct Lake on F32, the table must be accessed in smaller chunks via views.

Is increasing capacity the only solution for large tables?

No. While increasing capacity (e.g., to F64 or higher) raises the row limit, it increases costs. Using views to filter or aggregate data allows you to stay within the F32 limits, meeting the 'minimize costs' requirement.

More DP-700 FAQ →

Community Votes

B
50%
D
50%

50% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 17 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 17

  1. PBridge 👍 7 Answered B
    Changing surrogate keys from MD5 (string) to integers improves query speed, storage efficiency, and reduces costs.
  2. 2bc006e 👍 6 Answered D
    D. https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#fabric-capacity-requirements '' For Direct Lake semantic models, Max Memory represents the upper memory resource limit for how much data can be paged in. For this reason, it's not a guardrail because exceeding it doesn't result in a fallback to DirectQuery mode; however, it can have a performance impact if the amount of data is large enough to cause excessive paging in and out of the model data from the OneLake data. ''
  3. 92ef42d 👍 5 Answered D
    D - Capacity. F32 is too low
  4. kaushikcbs 👍 4 Answered B
    Modify the surrogate keys to use a different data type Why? - MD5 hash surrogate keys are 128-bit values, which can be inefficient for large datasets. - Switching to a more efficient data type (such as BIGINT or INT) reduces storage and processing overhead, improving query performance. - Smaller data types are faster to process, leading to better indexing and query execution. Answer validated with ChatGPT
  5. Rozamunde 👍 4 Answered D
    Duplicate of Question#5
Show 12 more comments
  1. Acrious 👍 3 Answered B
    While adding capacity would possibly do this, minimizing costs pushes us to select B, as changing a string type to an INT type would improve performance. Will it be enough... no way to measure but it would be the first step I would take
  2. ca_acc 👍 3 Answered D
    I dunno if this answer is correct within the exam. But it only can be: D. 300 Mio Row Lmitations in a warehouse at F32. Otherwise, we could split into to Views, to be within the Row Limits of 200 and 300 rows, for two different Years.
  3. Rozamunde 👍 3 Answered D
    https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-overview#:~:text=model%20permissions.-,Fabric%20capacity%20requirements,-Direct%20Lake%20semantic Limitation of Direct Lake/F32 - Rows per table --> 300 millions
  4. gretito_g 👍 3 Answered B
    Modify the surrogate keys to use a different data type.
  5. 32950cb 👍 2 Answered B
    The core issue is that MD5 hash surrogate keys are stored as strings (VARCHAR/CHAR). At 500 million rows in a fact table, string-based joins and lookups are significantly more expensive than integer-based ones. This is the root cause of both the performance degradation and potentially the Direct Lake fallback errors (which occur when data types or column cardinality exceed Direct Lake thresholds).
  6. Bin_Hashim 👍 2
    Good point but another point DW1 contains a single fact table that has grown from 200 million rows to 500 million rows during the past year. F32 Capacity ** Tables in a Power BI semantic model using Direct Lake mode on an F32 capacity are limited to 300 million rows per table any comments from the Team
  7. VenkataPhaniPavanKumar 👍 2 Answered D
    We should increase the capacity. Check this explanation https://www.youtube.com/watch?v=LX3EJX-LIFY&list=PLO3dD0hSou5e4ErRvooMc-ifeotjAt06g&index=4
  8. 5d361b3 👍 2
    wont increasing the capacity increase cost ?
  9. raweb 👍 2 Answered D
    Number of rows.. > Capacity
  10. nahida 👍 1 Answered B
    The warehouse uses MD5 hash surrogate keys, and the fact table has grown to 500 million rows. Hash-based keys can consume more storage than numeric surrogate keys. Using a more efficient data type can reduce storage and memory requirements, potentially improving Direct Lake query performance while minimizing operational costs.
  11. bcbc59b 👍 1
    Did you consider how much ETL cost will increase? Using and int key requires a join of fact and dimension tables to assign the keys while a hash does not.
  12. EddEe 👍 1 Answered B
    MD5 Performance: Large, 32-character string keys can be less efficient for joins and storage compared to 8-byte integers.

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