Harvey Moves Review Table Sorting and Filtering to Backend as Loading Gains Reach 5.8x

Harvey has moved sorting and filtering for Review Tables to its backend, changing how legal teams open large document reviews and reducing how much table data the browser must process at once. The largest loading gain is 5.8x for tables containing 10,000 to 100,000 cells.

Review Tables present document analysis in a grid: each file occupies a row, while columns hold questions and answers about it. A cell answer can include model reasoning and citations to the underlying document. The layout lets teams compare responses across many files.

Previously, the browser received the complete table and handled sorting and filtering locally. When a review grew to thousands of rows, that work could slow the interface, leave it unresponsive or prevent it from loading. The redesign splits the retrieval process into smaller steps.

Table details and values from the selected sort column load first. The backend returns row identifiers in sort order, which the client uses to request the records for the current page. More records are fetched in portions as a user moves through the table, instead of loading every row at the start. Because the initial request does not need every record, the browser can display a page without first receiving the full table. The ordered identifiers preserve the selected sorting as more records arrive.

Loading gains vary by table size: 1.2x for fewer than 1,000 cells, 2.2x for 1,000 to 10,000 cells, 5.8x for 10,000 to 100,000 cells, and 4.2x for 100,000 to 500,000 cells. The highest figure applies to the 10,000-to-100,000-cell range; the largest size band has a 4.2x gain.

Review Tables can contain up to 10,000 Vault files, while direct uploads from a computer are capped at 50 files. Those limits and the speed ranges measure different things: each file becomes a row, and each question adds a column of answers. A table’s cell total therefore depends on both the number of files and the questions asked.

Postgres remains the source of truth, while Turbopuffer serves as a read interface. If a write to Turbopuffer fails or a schema mismatch is detected, the system can fall back to Postgres for reads and run a backfill job to restore the other layer.