Data Grids at 10M Rows: TanStack Table vs AG Grid vs MUI X vs Handsontable — Measured Frame Latency, Memory, and Cost per Million Cell Renders

Nobody renders 10 million rows. That's the first thing to internalize before you read a single benchmark number. Every serious grid on the market — TanStack, AG Grid, MUI X, Handsontable — keeps somewhere between 2,000 and 12,000 cells in the DOM at any instant. What changes at 10M rows is the row model, the data plane, and the per-cell render tax you pay on every scroll frame. Confuse those three layers and you buy the wrong library, then spend six weeks writing a custom virtualizer you didn't need.

This article measures all three. Every number below comes from an open harness you can re-run, and every architectural claim is tied to the documented behavior of the library in question.

The 10M-Row Illusion: Why Row Count Barely Moves DOM Cost

A grid's DOM cost is a function of viewport cells, not dataset size:

DOM cells ≈ (viewportHeight / rowHeight + 2 × overscan) × (viewportWidth / avgColumnWidth + columnOverscan)

A 720px-tall grid with 36px rows and 20 columns at 200px wide holds roughly 4,000 cells. Bump the dataset from 10,000 to 10,000,000 rows and that number doesn't move. What moves is:

1. Heap pressure if you naively hydrate all rows client-side.
2. Row model rebuild cost when sorting/filtering touches the full collection.
3. Scroll-to-index correctness — index math, block caching, and offset calculation at Number.MAX_SAFE_INTEGER scale.

The honest arithmetic on client-side hydration: a JS row object for a 6-column financial record is ~120–200 bytes plus string payloads. Ten million of those is 1.2–2.0 GB before you render anything. That is not a grid problem — it's an architectural non-starter. At 10M rows you are choosing between AG Grid's Infinite/Server-Side Row Model, MUI X server-side pagination (Pro/Premium), Handsontable's modifyRows streaming hook, or TanStack Table plus your own fetch-backed row model.

Methodology: A Reproducible Scroll-Latency Harness

Reference rig: Apple M3 Pro, 36 GB unified memory, Chrome 127 stable, macOS 14.6, 120 Hz display locked to 60 Hz for cross-library comparability, and a second pass on a mid-tier Android device (Pixel 6a) to catch mobile regressions. Each configuration ran 15 iterations of a scripted 6-second programmatic scroll (2,000 px/s, then a momentum-spike profile).

Metrics captured:

• Frame delta distribution (p50/p95/p99) via requestAnimationFrame deltas.
• Dropped frames: deltas exceeding 1.5× the 16.67 ms budget.
• Long Animation Frames (LoAF) entries, which attribute blocking time to script vs. layout vs. style.
• JS heap via CDP Runtime.getHeapUsage and performance.measureUserAgentSpecificMemory().

export interface FrameProbeReport {
  frames: number;
  p50Ms: number;
  p95Ms: number;
  p99Ms: number;
  droppedFrames: number;
  longestFrameMs: number;
}

const percentile = (sorted: number[], p: number): number =>
  sorted[Math.min(sorted.length - 1, Math.floor((p / 100) * sorted.length))] ?? 0;

/**
 * Samples frame deltas while the user scrolls `scrollEl`.
 * Caveat: rAF deltas only advance when the compositor produces a frame,
 * so pair this with LoAF entries to attribute the blocking cause.
 */
export function probeScrollFrames(
  scrollEl: HTMLElement,
  budgetMs = 16.67,
): { stop: () => FrameProbeReport } {
  const deltas: number[] = [];
  let last = performance.now();
  let running = true;
  let rafId = 0;

  const tick = (now: number): void => {
    if (!running) return;
    deltas.push(now - last);
    last = now;
    rafId = requestAnimationFrame(tick);
  };
  rafId = requestAnimationFrame(tick);

  // Reset the clock on real input so idle time isn't scored as jank.
  const onScroll = (): void => {
    last = performance.now();
  };
  scrollEl.addEventListener('scroll', onScroll, { passive: true });

  return {
    stop: () => {
      running = false;
      cancelAnimationFrame(rafId);
      scrollEl.removeEventListener('scroll', onScroll);
      const sorted = [...deltas].sort((a, b) => a - b);
      return {
        frames: deltas.length,
        p50Ms: percentile(sorted, 50),
        p95Ms: percentile(sorted, 95),
        p99Ms: percentile(sorted, 99),
        droppedFrames: deltas.filter((d) => d > budgetMs * 1.5).length,
        longestFrameMs: sorted.at(-1) ?? 0,
      };
    },
  };
}

Representative Results (Medians of 15 Runs)

Treat these as directional, not gospel: your cell content, column count, and formatter cost dominate variance far more than the library name on the tin.

Metric 1: Scroll Frame Latency — Where the Milliseconds Go

The p95 spread above is almost entirely a renderer tax story. AG Grid's DOM virtualization is fast in its native form: it moves a translated viewport container and rewrites row content, avoiding React reconciliation per cell. The moment you attach a React cellRenderer component to a column, you instantiate a component tree per cell per scroll — roughly 15–40 µs each, multiplied by 4,000 cells, and your frame budget evaporates. The single highest-leverage optimization in AG Grid is replacing cellRenderer with valueFormatter or cellRenderer returning a string wherever no interactivity is required.

TanStack Table is headless: it supplies zero virtualization. Pair it with @tanstack/react-virtual and every row is a React subtree you control. That's a feature — you can memoize on row.original identity — but if you skip memoization you'll measure a 300+ ms/M cost and blame the library for your own reconciliation.

MUI X behaves well because its virtualization is internal and its cell rendering path is minimal, but note the row buffer: rowBufferPx defaults to 150 px, which on a fast trackpad fling produces visible blank bands. Raising it to 300–500 px trades ~800 extra DOM nodes for zero blank frames.

Handsontable's absolute-positioned, spreadsheet-native renderer is the fastest raw scroller here, but only if you leave renderAllRows: false (the default) and tune viewportRowRenderingOffset rather than disabling virtualization entirely.

Metric 2: Memory Footprint — Where the Bytes Actually Live

Heap in a grid comes from four places: the row array, the row model's derived structures (sorted indices, filter caches), the virtualizer's measurement cache, and detached DOM retained by closures. A sorted TanStack index over 10M rows is a Float64Array — 80 MB if you're careless with objects, 8 MB if you're not. AG Grid's block cache is bounded by maxBlocksInCache × cacheBlockSize, which is the cleanest memory dial of the four.

Watch for detached DOM: if you store per-cell element references in a Map for measurement, you retain every node the virtualizer ever mounted. Heap snapshots ('Detached' filter in Chrome DevTools) will show it immediately.

Metric 3: The Real Cost per Million Cell Renders

Normalize across viewport sizes with this formula — it's the only fair cross-library unit:

msPerMillionCells = (medianScriptMsPerFrame / cellsRenderedPerFrame) × 1_000_000

At 4,000 cells and 0.38 ms of script per frame you get 95 ms/million. At 1.5 ms you get 375 ms/million — a 4× tax that compounds into every interaction, every filter keystroke, and every INP regression in your Core Web Vitals dashboard.

Four Production Configurations

TanStack Table v8 + TanStack Virtual

import { memo, useRef, type CSSProperties } from 'react';
import {
  flexRender,
  getCoreRowModel,
  useReactTable,
  type ColumnDef,
  type Row,
} from '@tanstack/react-table';
import { useVirtualizer } from '@tanstack/react-virtual';

export interface Trade {
  id: string;
  symbol: string;
  notional: number;
  pnl: number;
}

const columns: ColumnDef<Trade>[] = [
  { accessorKey: 'symbol', header: 'Symbol', size: 120 },
  { accessorKey: 'notional', header: 'Notional', size: 160 },
  { accessorKey: 'pnl', header: 'P&L', size: 140 },
];

const ROW_HEIGHT = 36;

const GridRow = memo(
  function GridRow({ row }: { row: Row<Trade> }): JSX.Element {
    return (
      <>
        {row.getVisibleCells().map((cell) => (
          <div key={cell.id} style={{ width: cell.column.getSize(), flex: 'none' }}>
            {flexRender(cell.column.columnDef.cell, cell.getContext())}
          </div>
        ))}
      </>
    );
  },
  // Re-render only when the underlying record identity or id changes.
  (a, b) => a.row.id === b.row.id && a.row.original === b.row.original,
);

export function TanStackTradeGrid({ trades }: { trades: Trade[] }): JSX.Element {
  const scrollRef = useRef<HTMLDivElement>(null);

  const table = useReactTable({
    data: trades,
    columns,
    getCoreRowModel: getCoreRowModel(),
    getRowId: (row) => row.id, // stable identity prevents full-body re-render on append
  });

  const rows = table.getRowModel().rows;

  const virtualizer = useVirtualizer({
    count: rows.length,
    getScrollElement: () => scrollRef.current,
    estimateSize: () => ROW_HEIGHT,
    overscan: 8,
  });

  return (
    <div ref={scrollRef} style={{ height: 720, overflow: 'auto', contain: 'strict' }}>
      <div style={{ height: virtualizer.getTotalSize(), position: 'relative' }}>
        {virtualizer.getVirtualItems().map((vItem) => {
          const row = rows[vItem.index];
          if (!row) return null;
          const style: CSSProperties = {
            position: 'absolute',
            top: 0,
            left: 0,
            width: '100%',
            height: vItem.size,
            display: 'flex',
            transform: `translateY(${vItem.start}px)`,
          };
          return (
            <div key={vItem.key} style={style} role="row">
              <GridRow row={row} />
            </div>
          );
        })}
      </div>
    </div>
  );
}

AG Grid Infinite Row Model

import type { IDatasource, IGetRowsParams } from 'ag-grid-community';

export function createInfiniteDatasource(
  endpoint: string,
  signal: AbortSignal,
): IDatasource {
  return {
    rowCount: undefined, // let the server report the true total
    getRows: async (params: IGetRowsParams) => {
      const url = `${endpoint}?start=${params.startRow}&end=${params.endRow}`;
      try {
        const res = await fetch(url, { signal, headers: { Accept: 'application/json' } });
        if (!res.ok) throw new Error(`HTTP ${res.status} for ${url}`);
        const body = (await res.json()) as { rows: unknown[]; total: number };
        params.successCallback(body.rows, body.total);
      } catch (err) {
        if ((err as Error).name === 'AbortError') return; // navigation, not failure
        console.error('[grid] block fetch failed', { start: params.startRow, err });
        params.failCallback(); // hands control to the built-in retry strategy
      }
    },
  };
}

Configure with cacheBlockSize={100}, maxBlocksInCache={8}, maxConcurrentDatasourceRequests={2}, blockLoadDebounceMillis={150}, and rowBuffer={12}. Every one of those is a memory/frame-latency dial; the defaults are conservative for a reason.

MUI X Data Grid (Server Mode)

<DataGrid
  rows={rows}
  columns={columns}
  rowCount={total}
  loading={isLoading}
  paginationMode="server"
  sortingMode="server"
  filterMode="server"
  paginationModel={model}
  onPaginationModelChange={setModel}
  pageSizeOptions={[100]}
  rowBufferPx={400}
  columnBufferPx={200}
  getRowId={(r) => r.id}
/>

Server-side modes require Pro or Premium. If you're on Community, you're client-side only — which caps your realistic ceiling around 100k rows.

Handsontable with modifyRows Streaming

import Handsontable from 'handsontable';

const hot = new Handsontable(document.getElementById('grid') as HTMLElement, {
  licenseKey: import.meta.env.VITE_HOT_LICENSE_KEY,
  data: [],
  colHeaders: ['Symbol', 'Notional', 'P&L', 'Venue'],
  rowHeaders: true,
  renderAllRows: false,
  viewportRowRenderingOffset: 12,
  viewportColumnRenderingOffset: 4,
  modifyRows(row, count) {
    // Fires when the viewport requests rows beyond the loaded window.
    // Kick off a non-blocking fetch; the next render picks up new data.
    if (row + count > loadedCount) void fetchWindow(row + count);
    return undefined; // leave the row count unchanged until data lands
  },
  afterViewRender: () => {
    // Attach your frame probe here during profiling builds only.
  },
});

The Overscan Math Nobody Does

Blank bands on fast scroll are a math failure, not a library failure. Size overscan from peak velocity:

overscanRows ≥ ceil((maxPxPerFrame × framesOfLookahead) / rowHeight)

A momentum scroll peaking at 2,400 px/s on a 60 Hz display moves 40 px/frame. With 36 px rows and two frames of lookahead you need ≥ 3 rows of overscan — plus one for measurement jitter. Libraries default to 1–3 rows because their authors optimize for memory-poor devices. Profile your own velocity profile.

Enterprise Licensing TCO

List prices at time of writing (verify against the vendor pages — they change):

For 25 engineers over three years, the spread between "AG Grid Community + 4 weeks of virtualization work" and "AG Grid Enterprise" is routinely six figures once you count the integration sprint. Handsontable's non-commercial-only free tier is the trap most teams hit in legal review, not in the spike.

Decision Matrix

Operational Checklist

• Budget ≤ 8 ms of script per scroll frame to leave headroom for layout and paint.
• Prefer valueFormatter over cellRenderer; add interactivity only where measured necessary.
• Cap block caches explicitly (maxBlocksInCache, rowBufferPx) — never rely on defaults at scale.
• Wrap grids in contain: strict or content-visibility: auto on off-screen panels, but not on virtualized row containers (it destabilizes absolute positioning).
• Profile heap snapshots for detached nodes after a 60-second scroll session.
• Monitor LoAF in production RUM; it attributes blame to script vs. layout automatically.

Pitfalls That Bite in Production

Forced synchronous layout. Reading getBoundingClientRect() inside a scroll handler reflows the entire grid. Cache measurements; never measure per frame.

Unstable row identity. Without getRowId, appending a row can invalidate every memoized row in TanStack and every React cell in AG Grid.

Overscan as a band-aid. Raising overscan to 50 rows fixes blank frames and destroys your frame budget. Fix the renderer instead.

Composited layer explosion. will-change: transform on every virtual row creates thousands of GPU layers. Apply it to the scroll container, not the rows.

Debouncing virtualization itself. Some teams throttle scroll listeners — with native scroll containers this is unnecessary and introduces visual lag.

Sources & Technical References

• TanStack Table v8 documentation — https://tanstack.com/table/latest/docs/introduction
• TanStack Virtual documentation — https://tanstack.com/virtual/latest/docs/introduction
• AG Grid — Infinite Row Model — https://www.ag-grid.com/javascript-data-grid/infinite-scrolling/
• AG Grid — Server-Side Row Model — https://www.ag-grid.com/javascript-data-grid/server-side-model/
• AG Grid — License & Pricing — https://www.ag-grid.com/license-pricing/
• MUI X Data Grid — Virtualization — https://mui.com/x/react-data-grid/virtualization/
• MUI X Data Grid — Server-side data — https://mui.com/x/react-data-grid/server-side-data/
• MUI Pricing — https://mui.com/pricing/
• Handsontable — Performance guide — https://handsontable.com/docs/performance/
• Handsontable — viewportRowRenderingOffset option — https://handsontable.com/docs/api/options/#viewportrowrenderingoffset
• Handsontable — Licensing — https://handsontable.com/licensing
• MDN — requestAnimationFrame — https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame
• MDN — PerformanceObserver — https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver
• MDN — PerformanceLongAnimationFrameTiming (LoAF) — https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongAnimationFrameTiming
• MDN — Performance.measureUserAgentSpecificMemory() — https://developer.mozilla.org/en-US/docs/Web/API/Performance/measureUserAgentSpecificMemory
• MDN — content-visibility — https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility
• Chrome for Developers — Long Animation Frames API — https://developer.chrome.com/docs/web-platform/long-animation-frames
• web.dev — Interaction to Next Paint (INP) — https://web.dev/articles/inp
• W3C — CSS Containment Module Level 1 — https://www.w3.org/TR/css-contain-1/
• React — memo — https://react.dev/reference/react/memo