Performance Benchmarks
All estimates on this page are based on code structure analysis and architectural reasoning, not synthetic benchmarks run in a controlled environment. Actual performance varies significantly based on column complexity, cell renderer cost, browser, device hardware, and React version.
Render Cost
Approximate render times for a table with default feature flags enabled (sorting, filtering, pagination, column visibility).
Bundle Impact
Approximate minified and gzipped sizes for each module. Peer dependencies (React, TanStack Table, Radix UI, etc.) are excluded from these figures.
Peer dependencies — including React, @tanstack/react-table, Radix UI primitives, and next-intl — are not included in the figures above. Bundle size in practice will depend on which peer packages your application already uses.
Memory Model
- Config object — approximately 500 bytes; frozen at creation time via
Object.freeze, preventing accidental mutation. - Table instance — lightweight; TanStack Table stores minimal bookkeeping state and delegates heavy lifting to derived computations.
- Row models — filtered, sorted, and paginated row models share references to original row data objects; no deep copies are made.
- URL sync — a single
URLSearchParamsinstance is created per navigation event; no continuous polling.
Scaling Recommendations
- Under 500 rows — client-side filtering, sorting, and pagination work well with default settings.
- 500–5,000 rows — client-side remains viable but monitor re-render cost, especially with complex cell renderers. Disable unused features.
- 5,000–50,000 rows — move to server-side pagination. Send only the current page of data; let the server handle filtering and sorting.
- 50,000+ rows — full server-side mode required. Consider row virtualization (planned feature) for cases where all rows must be visible simultaneously.