Performance and limits
Every grid is fast in a demo. This page publishes how fast Rowhouse is at 1,000, 5,000, 10,000 and 50,000 rows, how it was measured so you can measure it again, and every limit you can meet, with the reason it is there.
Every row loaded
milliseconds; mostly Salesforce reading 2,000 rows at a time
Why it matters
A grid’s row ceiling and speed are usually found out after purchase. Conga Grid’s own documentation limits a view to 1,000 rows and a paste to 100. Across the 32 grids in our October 2026 research we found no other benchmark published with its method: the rest publish nothing, or a round number. Rowhouse publishes both, with a script you can run, because a number you can check is worth more than a number you have to believe.
Reading the numbers
Every number is a timing the grid records itself. First row runs from the grid starting to load to the first row painted on screen. Full render runs to every loaded row painted, and at 10,000 and 50,000 rows it is mostly server time. Sort runs from a header being activated to the loaded rows painted in the new order; sort settled runs until the grid is no longer busy, which at 50,000 rows includes asking the server for the first 10,000 rows in the new order. Edit commit runs from an edit being committed to the cell painted with its new value.
The first-row times were measured before the grid opened in one server call; first rows now arrive sooner than shown, and the next pass will measure it.
See it as your users will
The first row comes quickly at any size
Under 1.8 seconds at every size measured, because the first page is always 200 rows, whatever the list holds.
First row on screen
milliseconds from opening the grid; the first page is always 200 rows
Sorting stays near half a second
A click on a header re-sorts thousands of loaded rows in about half a second or less. At 50,000 rows, the server then sends the first 10,000 in the new order.
Sorting the loaded rows
milliseconds from a click on a header to the new order on screen
At 50,000 the grid then fetches the first 10,000 rows in the new order from Salesforce: about 4.4 s with 5 columns and 8.2 s with 20.
Edits land in a blink
From pressing Enter to the new value on screen, a fraction of a second at every size.
An edit appearing in its cell
milliseconds from pressing Enter to the new value on screen
Every limit at a glance
Each limit is there for a reason you can see: how much a browser draws smoothly, or how much Salesforce lets one transaction do.
In detail
Only the rows near the screen are drawn
The grid keeps thousands of records in memory but draws only the rows around the screen, so scrolling stays smooth at 10,000 rows, while screen readers still hear the right row positions.
Large lists load as you go
The first 10,000 records load when the grid opens. Past that, more load as you scroll, 2,000 at a time, up to 100,000 — and a sort, search or filter asks the server for the first rows in the new order rather than sorting only what has loaded.
Totals from the server
Subtotals and the Total row are worked out on the server across every matching record, so they are right at 50,000 rows when only 10,000 are loaded.
Saves sized for Salesforce
A save goes in batches of 200, each its own transaction, so one bad record never takes 9,999 good ones with it, and your org’s own automation runs within its limits.
Lightning Web Security and Locker
Rowhouse works under Lightning Web Security and under Lightning Locker, so an org that has not turned on Lightning Web Security can still run it. The benchmark ran with Lightning Web Security on; a Locker pass covers the 50,000-row lines.
Measured, with the script
The median of five runs at each size. The method is in the repository’s docs/benchmarks.md and the script beside it, so anyone can run it again in their own org. Fewer columns help most: 20 columns take roughly twice as long as 5.
| Rows | Columns | First row | Full render | Sort | Sort settled | Edit commit |
|---|---|---|---|---|---|---|
| 1,000 | 5 | 876 ms | 1,208 ms | 124 ms | 156 ms | 47 ms |
| 1,000 | 20 | 1,438 ms | 1,742 ms | 335 ms | 366 ms | 136 ms |
| 5,000 | 5 | 931 ms | 2,737 ms | 206 ms | 239 ms | 79 ms |
| 5,000 | 20 | 1,495 ms | 4,693 ms | 439 ms | 475 ms | 206 ms |
| 10,000 | 5 | 988 ms | 4,473 ms | 330 ms | 359 ms | 120 ms |
| 10,000 | 20 | 1,701 ms | 8,224 ms | 535 ms | 576 ms | 276 ms |
| 50,000 (10,000 loaded) | 5 | 965 ms | 4,511 ms | 232 ms | 4,358 ms | 147 ms |
| 50,000 (10,000 loaded) | 20 | 1,478 ms | 8,336 ms | 534 ms | 8,221 ms | 273 ms |
Every limit, and why
Each limit is there for a reason you can see: how much a browser draws smoothly, or how much Salesforce lets one transaction do.
| Limit | Value |
|---|---|
| Rows loaded when the grid opens | 10,000 |
| Rows reachable by scrolling | 100,000, loaded 2,000 at a time |
| First page (Page Size) | 1 to 2,000; 200 when blank |
| Records in one save | 10,000, in batches of 200 (fewer in a logging grid when many fields change) |
| New rows in one save | 200 |
| A related record's field | up to 5 lookups away, each to one kind of record |
| Browser wait for a save | 120 seconds, then a "still running" message |
| Cells in one paste | 10,000; larger pastes refused, not cut short |
| Undo steps | 100 (unsaved edits only) |
| Rows in one selection | 10,000 |
| Import file | 10,000 rows, 20 MB; batches of 200 |
| Grouping | 3 levels, 5,000 groups |
| Child table levels | 3 |
| Records per action call | 50 |
| Delete every match | 50,000 (not offered above that) |
| Columns one user can filter at once | 10 |
| Formulas per grid (columns and rules together) | 10 |
| Child total columns per grid | 5 |
| Card layout below | 480 px |
| Frozen columns | 0 to 5 |
| Log entries per transaction | 5,000 |
- 100,000 rows are reachable, not benchmarked. The published, verified figure is 50,000.
- Twenty columns take roughly twice as long as five. Fewer columns help most.
- Salesforce itself takes time to draw the page and hand the grid its code; no component can shorten that.
- Lookup search is slower than Salesforce’s own on objects with millions of rows.
Against the paid grids
Performance and limits: questions
How was the benchmark measured?
In a Developer Edition org with Lightning Web Security on, in Chrome 154 on macOS 27.0.1 on an Apple M3 Max, as the median of five runs at each size, in a tab that stayed visible for the whole run. The method and the script are in the repository, so you can run it in your own org.
Can Rowhouse handle 100,000 rows?
A grid can reach 100,000 rows by scrolling, loading 2,000 at a time. The benchmark is published to 50,000 rows, and that is the figure we stand behind.
Why is there a limit at all?
Each limit is there for a reason you can see: how much a browser draws smoothly, or how much Salesforce lets one transaction do. Larger pastes are refused rather than quietly cut short, so you never save half of what you meant.
Does Rowhouse slow down my org?
A grid saves in batches of 200 and makes no callouts. Its server time appears in the browser console for holders of the diagnostics permission set, so an admin can see exactly what a slow grid is doing.
Three things you can verify without asking us
Free. Not freemium, not a trial, not a tier.
Install it, assign the permission sets, build your first grid on the Grid Admin tab. Everything else is in the Grid Guide inside the app.