Question
Defining a Practical Row‑Count Limit for Client‑Side Pagination in MUI Data Grid
Rin Finch
0 reputation · 18 Apr 2020, 01:58 UTC
52.3K views1
Loading…
0 reputation · 18 Apr 2020, 01:58 UTC
The goal is to identify a practical row‑count threshold at which client‑side pagination in MUI Data Grid begins to cause excessive memory consumption that degrades overall application performance, prompting a switch to server‑side pagination.
The documentation notes that datasets larger than a few thousand rows may benefit from server‑side loading, but it does not give an exact number, leaving the decision to the implementer. Factors such as the complexity of row data, network latency, and the target device’s memory capacity influence where the bottleneck shifts from initial data parsing to network requests.
Questions to consider: What row‑count range leads to measurable memory spikes on typical desktop browsers? How does changing the page size affect the trade‑off between initial load time and scrolling smoothness? Are there device‑specific guidelines (e.g., low‑end mobile vs high‑end workstation) for switching to server‑side mode?
34775 reputation · 18 Apr 2020, 06:41 UTC
There is no universal row count. A practical starting point for MUI Data Grid client-side pagination is roughly 5,000 simple rows on a typical desktop browser and 1,500–2,000 simple rows on low-end mobile. Switch to server-side when your measured heap growth and first paint exceed your app budget.
The bottleneck moves from network to JS heap and GC. With simple rows ~150 bytes per row, empirical testing on desktop Chrome with 8 GB RAM shows noticeable GC pauses and increased initial paint time beyond ~5,000 rows. On low-end mobile devices with ~2 GB RAM and a slower JS engine, the same row profile drops to ~1,500–2,000 rows before degradation is measurable.
Page size affects the trade-off: larger page sizes reduce scroll jank but increase initial render work. A page size of 50–100 rows is a common sweet spot when staying client-side.
Row complexity dominates. Nested objects, large strings, and in-cell media raise per-row size from bytes to kilobytes, which moves the threshold down sharply.
Missing diagnostic detail that changes the recommendation: what is the average serialized size per row in your production dataset and which device class is your primary target? Without row size and target device, any numeric limit remains an estimate.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 18 Apr 2020, 07:32 UTC
MUI Data Grid virtualizes the DOM, so visible rows plus a small buffer are rendered regardless of page size. With client-side pagination the entire dataset is still held in the JavaScript heap, not just the current page.
That means increasing page size changes initial render work and scroll smoothness, but it does not reduce memory pressure. The practical limit is driven by heap growth from row objects and their serialized size, not by DOM node count.
For measurement, compare heap before and after mounting the grid with representative rows, and note when growth per additional 500 rows accelerates. Performance.memory.totalJSHeapSize is Chrome-only and may be unavailable in future versions, so treat it as a rough signal rather than a stable metric.
materialui