What we have measured, and what each number was measured on.

Every figure here is our own, from the kit's capability table, with the machine and the conditions it was taken under. None is compared with another product.

The numbers.

Measure	Result	Conditions
Acknowledged writes lost, process killed	0 of 1,000	Every write synced (TESSERA_WAL_SYNC=always). With periodic sync, 4 and 2 were lost in two runs, which is the documented trade-off.
Recovery after a kill	16–19 ms	A 1,000-row log; it grows with the size of the write-ahead log.
Memory per small row	about 5 KB, plus 1 GB	Planning figure. 4.4 KB a SQL row and 4.1 KB a graph record after a restart; 7.4–9.9 KB while serving 100,000 rows.
Server start	115 ms	Apple M2 Pro, 10 cores.
Read scaling	about 5.6–6.1× at 8 readers	10 cores, readers only; the curve flattens at 8–12 readers.
Streaming, first byte	1.8 ms	15,000 rows; 3,000,000 rows served with no memory growth.
openCypher TCK	3,893 of 3,897	Every scenario counted, against the unmodified suite.

← Swipe for the rest of the table →

← Drag for the rest of the table →

Benchmarks, self-reported.

LDBC SNB Interactive

The 14 complex reads, run on official generator data at scale factor 0.1 (448,684 entities, 2,164,444 relationships): all fourteen answer, twelve in under 500 ms and eight in under 25 ms. Self-reported and not audited; the short reads and updates are not implemented.

Fraud benchmark

Six workloads over a generated bank book of 497,469 records, on one machine and one thread, in the engine rather than over HTTP. See the financial-crime page for the figures and what they do not prove.

The largest graph loaded

15,000,000 records. A billion records is an extrapolation, not a demonstrated deployment.

Clusters

The largest Raft cluster tested over real network sockets is 5 nodes; 9 nodes were tested in one process over a simulated network.

Cluster limits in 1.0

Not every write goes through the Raft log yet: transactions, batch SQL, files, rules, schedules and writes over the Postgres, Bolt and gRPC doors are not copied to the other nodes, and the log is not trimmed. Automatic failover of a data node, rolling upgrades and read repair are not built.