Four operations, on the whole cluster, at every release.
Write, read, traverse and scan, each measured with every node and every disk working at once. Each figure is shown with the release it was taken at, the machine and the door it was measured through, the concurrency behind it, how busy the disks, CPU threads and memory were, where the data was served from, and how it has moved from release to release.
These figures are generated from the release record when the page is built. None is typed by hand, and a figure that was not measured is shown as not measured, never as zero.
Where the four operations stand
Latest published release r11.70, 5 October 2026. Every figure on this page is read from the release record when the page is generated; none is typed.
| Operation | Now | Unit | Release |
|---|---|---|---|
| Write | 55 million | rows per second | r11.70, 5 October 2026 |
| Read | 13.9 million | ids per second | r11.70, 5 October 2026 |
| Traverse | 704 million | edge hops per second | r11.70, 5 October 2026 |
| Scan | 232 million | rows per second | r11.70, 5 October 2026 |
The figures come from one cluster of 2 nodes (8 CPU cores and 16 threads on each): 4 disks at 7.6 GB/s each (30.4 GB/s together), 16 CPU cores and 32 threads in all, and memory bandwidth of about 62 GB/s per node (124 GB/s together).
How each figure is taken
- Door. The engine's own cluster interface, called inside the measuring program that runs on each node. No network protocol, web server or client library stands in front of it, so these are the engine's figures, not a wire's.
- Concurrency. One concurrent caller per CPU thread on every node, 32 in all, a width the measuring program works out from the cluster each time. The release record does not store the width per release.
- Container size. Every figure counts 64-byte containers, the engine's standard unit. No figure on this page uses the compact 8-byte cell form.
- Memory. Write and scan are run with the engine's memory tier switched off, so they are bounded by the disks. Traverse is run with a 1 GiB memory budget on each node.
Write: 55 million rows per second
Rows appended to the store: 8,000,000 rows a run, written by concurrent callers on both nodes, each row landing on the node that owns it. The figure is the median of three runs.
The release record keeps the utilisation of disks, CPU threads and memory for the scan only, so it is not recorded for this operation at this release. Per-core, per-disk and per-channel detail on each node is recorded only for releases published after the release gate began to keep it.
Read: 13.9 million ids per second
Ids resolved and returned in batches of 256 by concurrent callers on both nodes. Each id returns one 64-byte container. The figure is the third of three passes over the same ids: cold, warm, warm again.
The release record keeps the utilisation of disks, CPU threads and memory for the scan only, so it is not recorded for this operation at this release. Per-core, per-disk and per-channel detail on each node is recorded only for releases published after the release gate began to keep it.
Where the data was served from
| Level | At this release |
|---|---|
| CPU cache (first level) | not recorded for this operation |
| Memory tier (the engine's own bounded memory budget) | not recorded for this operation |
| Disks | not recorded for this operation |
The release record keeps no tier row for this operation, so none is printed.
Traverse: 704 million edge hops per second
Four-hop graph walks from 20,000 seed nodes over a graph of 3,000,000 nodes and about 30 million edges, by concurrent walkers on both nodes, each node holding a 1 GiB memory budget that the walks' working set fits. Every edge followed counts as one hop.
The same walks with a memory budget smaller than the graph (streaming from disk) are not in the published release record at this release.
The release record keeps the utilisation of disks, CPU threads and memory for the scan only, so it is not recorded for this operation at this release. Per-core, per-disk and per-channel detail on each node is recorded only for releases published after the release gate began to keep it.
Where the data was served from
| Level | At this release |
|---|---|
| CPU cache (first level) | not recorded for this operation |
| Memory tier (the engine's own bounded memory budget) | 11.1% of accesses, in the companion run whose memory budget is smaller than the graph |
| Disks | not recorded for this operation |
The memory-tier figure was taken in a companion traversal run with a memory budget smaller than the graph, so the walk reaches the disks; the headline figure above comes from the run whose working set fits the budget, and the release record keeps no tier row for that run.
Scan: 232 million rows per second
A full scan of 8,000,000 rows, a 512 MB image of 64-byte rows, counting the rows that match, by concurrent callers on both nodes. A scan is counted in whole scans per second, so the rate moves in steps of 0.512 GB/s; rows per second is that rate divided by 64 bytes a row.
Utilisation during the scan
| Resource | At this release |
|---|---|
| Disks at 95% of their ceiling or more | 0 of 4 |
| CPU threads at 95% busy or more | 0 of 32 |
| Disk throughput, all disks together | 28.2 GB/s of 30.4 GB/s |
| Memory bandwidth, both nodes together | 19.4 GB/s of 124 GB/s |
Recorded with the release for its scan. Per-node, per-disk and per-thread detail is kept only for releases published after the release gate began to record it.
Where the data was served from
| Level | At this release |
|---|---|
| CPU cache (first level, counted by the processor) | 95% of loads, during the scan |
| Memory tier (the engine's own bounded memory budget) | switched off for the scan, by design |
| Disks | 92.7% of the disk ceiling (28.2 of 30.4 GB/s) |
The cache figure and the disk share are the scan window's own. The release record keeps no per-level share of accesses for the disks, so the disk row is throughput against the ceiling, not a share of accesses.
How to read these figures
- Whole cluster. Each figure is taken with every node and every disk working at once, not one machine in isolation.
- Measured at the release. The release gate measures each release before it is published, and a release that regresses is not published. The trend shows only published releases; 7 other measured build(s) in the record are not plotted.
- The setup changed over time. Early releases were measured with fewer concurrent callers and smaller runs, so the early part of each trend should be read with that in mind.
- A gap is a gap. A release with no figure for an operation leaves a gap in its chart. Nothing is estimated or carried forward.
- Could not judge. Where an instrument could not measure something, the page says so and why, in general terms. A zero is never printed for a value that was not measured.
- Utilisation. The release record keeps the scan's utilisation of disks, CPU threads and memory. Per-core, per-disk and per-channel detail on each node is recorded only for releases published after the release gate began to keep it; until then the page says so rather than showing a number.
- Early measurement rows. Twelve measurement rows from 13 September 2026 recorded no value, and early rows that recorded a zero cannot be told from a measurement. Neither is used here.
- Per-channel memory bandwidth and network traffic are not measured on this hardware, so neither is shown.
Generated from the release record: release_series.json a2f73481e4fe and release_baseline.json c9e12858dc90 (the first 12 characters of each file's SHA-256). The baseline is cross-checked against the series: each of its four figures must equal the median of the last published releases it names, and it names r11.70.