Four operations, on the whole cluster, at every release.

Where the four operations stand

Latest published release r11.152, 3 November 2026. Every figure on this page is read from the release record when the page is generated; none is typed.

The figures come from one cluster of 2 nodes (AMD EPYC 4345P, 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). This is the cluster the release gate measures on; every release is measured again before it is published.

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.
• Record size. Every figure counts 64-byte records.
• Memory. Write and scan are run with the engine's memory cache switched off, so every byte they touch goes to or comes from the disks. Traverse is run with a 1 GiB memory budget on each node.

Write: 79.5 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. A run is 512 MB and lasts a fraction of a second, and its clock stops only after the disks have confirmed every row, so this is a short burst, not a sustained rate. The disk figures below are sampled once a second over the whole phase, so they read far below the run's own rate. Each node writes the rows it owns, from callers on that node; the figure is the two nodes added together. No row crosses between nodes in this measurement, so it is not a figure for writes spread across a cluster.

Utilisation during write

Measured with 16 concurrent callers on each node.

Memory bandwidth is counted per node. Per-channel bandwidth is not measured on this hardware, and CPU threads are counted, not listed one by one.

Measured memory bandwidth is being re-proven after the 2026-10-11 control audit: the instrument read only part of the machine's memory traffic, so its figures could read low; they return when re-measured.

Read: 14.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 record. The figure is the third of three passes over the same ids: cold, warm, warm again.

Utilisation during read

Measured with 32 concurrent callers across both nodes.

Memory bandwidth is counted per node. Per-channel bandwidth is not measured on this hardware, and CPU threads are counted, not listed one by one.

Measured memory bandwidth is being re-proven after the 2026-10-11 control audit: the instrument read only part of the machine's memory traffic, so its figures could read low; they return when re-measured.

Where the data was served from

Each share is the fraction of this operation's reads that were served from memory or had to be read from disk, counted in the operation's own run at the release gate.

Traverse: 966 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, so it streams from disk: 634 million edge hops per second.

Utilisation during traverse

Measured with 32 concurrent callers across both nodes.

Memory bandwidth is counted per node. Per-channel bandwidth is not measured on this hardware, and CPU threads are counted, not listed one by one.

Measured memory bandwidth is being re-proven after the 2026-10-11 control audit: the instrument read only part of the machine's memory traffic, so its figures could read low; they return when re-measured.

Where the data was served from

Each share is the fraction of this operation's reads that were served from memory or had to be read from disk, counted in the operation's own run at the release gate. The companion run uses a memory budget smaller than the graph, so its walks reach the disks.

Scan: 232 million rows per second

A full scan of 8,000,000 rows, 512 MB 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 scan

Measured with 32 concurrent callers across both nodes.

Memory bandwidth is counted per node. Per-channel bandwidth is not measured on this hardware, and CPU threads are counted, not listed one by one.

Measured memory bandwidth is being re-proven after the 2026-10-11 control audit: the instrument read only part of the machine's memory traffic, so its figures could read low; they return when re-measured.

Where the data was served from

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.

Memory: knowledge graph and retrieval

The memory checks of release r11.152, 3 November 2026: 17 of 17 pass. Each is run by the release gate on our own synthetic test set of 2,000 documents. They say whether a capability works; they are not a comparison with any other system.

Retrieval quality (how often the right passage is found with and without following the graph, and how often an answer is grounded) is also measured on every release, on the same test set. Those figures are diagnostics, not results: they are not published until they are measured on a public dataset against another system set up to answer the same questions.

How to read these figures

• Whole cluster. Each figure is taken on both nodes at once, with all of their disks, not one machine in isolation; the tables above show how busy each disk actually was.
• Measured at the release. The release gate measures each release before it is published and stops a release that falls on a row it blocks on; some rows are reported without blocking, so a published release can sit below the one before it, as the read trend shows in late September. 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 a5b3b0ce2f36 and release_baseline.json c20b14479fa8 (the first 12 characters of each file's SHA-256). The baseline names r11.152 and is cross-checked against the series. Write, Read, Traverse and Scan: each figure equals the median of the releases the gate's record says it was taken over.