The spreadsheet had 10,000 rows and 26 columns. Every cell in columns B through Z contained a formula. Column A held the raw data: names, dates, numbers, strings of various lengths. The formulas in the other columns referenced column A, referenced each other, and in some cases referenced cells on other sheets within the same workbook.
It was the largest spreadsheet anyone had fed to the Sheets twin, and Navan had built it specifically to answer one question: would the twin hold?
"The dependency graph for this workbook has 234,000 edges," Navan reported. He was monitoring the twin's memory consumption and CPU usage as three agents simultaneously queried and modified the spreadsheet. "Every cell change triggers a recalculation cascade. The worst case is changing a cell in column A that's referenced by every formula in its row and transitively by formulas in other rows."
Agent One changed a value in cell A1. The twin recalculated 8,847 cells in 1.2 seconds. Navan noted it down.
Agent Two changed a value in cell A5000, in the middle of the spreadsheet. The twin recalculated 4,312 cells in 0.7 seconds. The recalculation was faster because the formulas in the upper half of the spreadsheet didn't depend on row 5000.
Agent Three added a new row at position 5001, which shifted all rows below it by one. Every formula that referenced a row below 5001 needed its row references updated. The twin adjusted 127,000 cell references in 3.4 seconds.
"That row insertion was the real test," Jay said. "Row insertions in the middle of a large spreadsheet are pathological for reference updating. Real Sheets handles it through a lazy evaluation system—it doesn't update all references immediately, just marks them dirty and recalculates on access."
"Does the twin do the same?"
"We implemented eager evaluation first. It was simpler. But at this scale, eager evaluation is too slow. So we switched to lazy evaluation for reference updates: mark dirty, recalculate on read. The twin now matches Sheets' performance characteristics as well as its behavioral ones."
Justin reviewed the numbers. "Memory consumption?"
"340 megabytes for the full workbook state including the dependency graph," Navan said. "The real Sheets doesn't expose memory consumption, so we can't compare directly. But 340 megabytes is well within what a single twin binary can handle."
"Run the stress test," Justin said.
The stress test was all three agents modifying the spreadsheet simultaneously for five minutes straight. Random cell updates, row insertions, column additions, formula modifications. The twin had to maintain consistency across all three agents' views, resolve conflicts through its operational transformation layer, and keep the dependency graph accurate as the spreadsheet's structure changed beneath it.
Five minutes later, the twin was still running. No crashes. No data corruption. All three agents reported consistent state. The recalculation times had increased under load—peak was 4.8 seconds for a full-column recalculation—but the twin had not failed.
"It holds," Navan said. He let himself smile.
"At 10,000 rows," Justin said. "What about 100,000?"
Navan's smile became more complicated.
234,000 edges in the dependency graph for a 10,000-row spreadsheet. Now I understand why large Google Sheets get slow. The formula graph is the real structure, not the grid.