RadzenPivotDataGrid Perfomance issues

Radzen.Blazor Components
1

Hi Radzen team,

We are using RadzenPivotDataGrid in a Blazor Server application and are running into performance issues, especially during drilldown / expand operations.

Our use case is financial reporting / analysis. The pivot is used for accounting-style data across multiple companies and dimensions, for example:

  • different companies

  • cost accounts / general ledger accounts

  • dimensions / cost centers / organizational dimensions

  • accounting years and periods

  • different aggregates such as amounts and counts

Because of that, the number of possible row/column combinations can grow quickly depending on the selected layout.

We already tried to reduce the input data before binding it to the pivot:

  • we load the data once when the user clicks Load data

  • we do not fetch additional data when the user drills down

  • we pre-aggregate the source rows before passing them to RadzenPivotDataGrid

  • we also removed unnecessary dimensions from the source data to reduce cardinality

Even after that, the pivot can still feel slow:

  • drilldown is noticeably slow even with only 2 selected companies

  • with 5 companies, expansion becomes even slower

  • sometimes after drilldown the UI looks like the “busy” phase is over, but the rows still take extra time to appear

  • we also noticed that, without manually padding missing combinations with zero rows, not all selected companies always appear in certain drilldown branches

From looking at the source code, it seems that RadzenPivotDataGrid builds cached row/column structures and computes aggregates from the already bound dataset, rather than loading data lazily per drilldown. That makes us wonder if the main bottleneck is the internal grouping/rendering itself.

So I’d like to ask:

  1. Is RadzenPivotDataGrid intended to work best with fully preloaded data, or is there a recommended pattern for lazy / on-demand drilldown loading?

  2. When a user expands a row group, does the pivot recompute visible structures and aggregates from the entire bound dataset?

  3. Are there recommended best practices or practical limits for:

    • number of distinct row groups

    • number of column leaves

    • number of aggregates

    • drilldown depth

  4. Does AllowPaging significantly improve pivot performance, or is it mainly UI paging after the pivot structure is already built?

  5. Is there any internal virtualization for the pivot body, row groups, or column groups?

  6. Do you recommend aggressive external pre-aggregation before binding data to the pivot?

  7. Is there any plan to support features like Top N + Others to reduce high-cardinality group expansion?

Environment:

  • Blazor Server

  • RadzenPivotDataGrid

  • financial / accounting data

  • multiple companies, accounts, dimensions, and periods

  • Radzen.Blazor version: 10

If helpful, I can provide:

  • a simplified reproduction

  • approximate row counts before and after pre-aggregation

  • the specific row/column/aggregate configuration that causes the slowdown

Thanks!

2

The only option to improve the performance in your case is to enable paging - virtualization is exactly the same as paging however it happens during scrolling and it’s not supported at the moment. Other than that you have full access to the entire source code and you can easily debug to see what’s slower in your scenario. We accept also pull requests/suggestions for features and optimisations!