How the React Data Grid stays fast at 100,000 rows, the props that tune rendering, and when to move paging to your backend.
On this page
The Data Grid is built to stay responsive on large datasets. This page explains how it does that and the levers you have when you need to tune it.
Why it’s fast
- Row virtualization. Only the rows in the scroll viewport (plus a buffer)
exist in the DOM — see Virtualization. A 100,000-row
grid renders a few dozen
<tr>elements, not 100,000. - Cheap cell values. Column
formatterruns on the scroll hot path and returns a string, so it stays cheap. Reserverender(which builds JSX) for the columns that truly need interactive content. - Debounced, race-safe fetches. In server-side mode, rapid state changes coalesce into one request and stale responses are dropped.
Tuning levers
| Lever | Effect |
|---|---|
rowHeight | The estimated row height (default 44). Set it close to your real height so the virtualizer sizes the scroll area accurately. |
overscan | Extra rows rendered above/below the viewport (default 10). Raise it if you see blank rows during fast scrolling; lower it to shave DOM nodes. |
formatter vs render | Prefer formatter for values on the hot path; render allocates elements per visible cell. |
| Stable props | Memoize items and columns (e.g. useMemo) so the grid doesn’t recompute row models on every parent render. |
When to go server-side
Client-side mode keeps the whole dataset in memory. That’s fine for tens of thousands of rows, but past what the browser can hold — or when the data lives in a database you don’t want to ship whole — move sorting, filtering and paging to your API with server-side data. The grid then holds only the current page.
Rules of thumb
- A few thousand to ~100k rows in the browser → client-side with virtualization.
- Beyond that, or data behind an API → server-side mode.
- Keep
formatterpure and cheap; it runs for every visible cell on every render.