A 15.95-million-pixel spacer div is what capped BGrid at 550,000 rows

A spacer that tall does not raise an exception. The layout engine stops honouring the height, the scroll area stops growing, and every row index derived from scrollTop starts pointing somewhere else. That is the failure the BGrid team reported on dev.to: React did not crash, memory was not exhausted, and the DOM never held 700,000 nodes ^[2]. It presents as a virtualization bug, because the component that looks broken sits downstream of the one that is.

Hold the constraint this way: the ceiling is priced in pixels and paid in rows. At roughly 29px per row, the budget BGrid was approaching bought 550,000 rows ^[3]. Put a 48px touch-height row in the same budget and it buys 332,291 ^[1]. The dataset itself is unchanged. Run the same division on a timeline at one pixel per second and the budget is about 184.6 days of track ^[2]. A log viewer with wrapped lines is the same sum with a taller unit. The million-row demo the team wanted would have needed 29,000,000px, roughly 1.8 times the height at which the layout was already misbehaving ^[3].

The v1.0.3 fix is to stop asking. Physical scroll position and dataset position are separated: the browser scrolls a bounded range it can handle, and BGrid maps that position into the logical range, then into a row index, then into rendered rows ^[5]. The ceiling was a consequence of the dependency, and the author states plainly that row 550,001 marks where that dependency broke down, not an intentional speed limit ^[9].

What you pay is the scroll contract. Once the physical range is deliberately smaller than the logical one, the ratio between them exceeds one by construction, so a scroll offset now names a set of rows that your mapping function resolves, rather than a single row directly ^[4]. Position restore, deep links and scroll-to-row, all of which used to work because the browser owned the mapping, now run through your code.

The 10,000,000-row result ^[7] transfers only under conditions the post half states. Row height has to be constant, because every figure in the writeup is a row count times 29px ^[3]. The row lookup has to be fast enough to run inside a scroll handler, since the mapping resolves an index and then needs data for it. And the bounded physical range has a value the post does not publish, which is the one number that tells you how coarse a single scrollbar drag becomes. The author says plainly that 10 million database records in browser memory is not the suggestion, and points at server-side processing at that scale ^[8].

The number worth writing down somewhere is your usable element height divided by your tallest row. That is the row index where the symptoms start and the cause stops being your code.