Key-value demo: cache speed, on disk, no hop
You are looking at Bitcoin address & tx keyspace188.97M keys as 64-byte containers in one Semurg substrate. Ask it to GET a million keys across every core and it runs the
real query live on this box, on data you can
download and re-run yourself.
Click an example in the agent rail, or type any GET, or ask to fan reads at max concurrency. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
A key to 64-byte-container GET is a seqlock read off the RAM-ring, fanned across every core, with the data durable on disk underneath. No separate in-memory store, no network round-trip. Total time, measured live.
the in-memory key-value leader
A HOP, AND A LOSS WINDOW. It is a separate server, so every GET crosses the network, and between fsyncs a crash drops the last writes (RDB or AOF is a persistence tax, not a guarantee).
semurg, one engine
cache-speed GETs, zero loss window. The compute runs on the data, so there is no hop, and every key is durable on disk the instant it lands.
Fast like a cache, durable like a database, one copy of the data.
The live Bitcoin value-flow graph, 188.97M nodes as 64-byte containers, GET off the seqlock ring. Measured live on this box, on data you can re-pull over Bitcoin P2P.
18.6MGET/s
97.7Kkeys read
8cores
241.3Kper core
5.2 mslatency
seqlock RAM-ring reads · durable on disk (disk=truth) · no network hop · no separate cache process
the answer
GET the resident keyspace across every core
GET fan-out
live result
keys read
97.7K
per core
241.3K
cores
8
latency
5.2 ms
every key a seqlock read off the RAM-ring, durable on disk, no network hop
1.9Mrandom GET/s
64.0K random point-lookups fanned across 8 cores, batched deep-QD, durable on disk
beats a networked in-memory cache's 1-5M GET/s, and durable on disk
durable on disk, zero loss window, no network hop
hit-rate + reads/s · cold / warm / hot
cold 0.1%
warm 1.0%
hot 98.9%
cold 113.9M/s
warm 1.75B/s
hot 3.59B/s
reads/s at each tier · cold straight off NVMe · warm from the RAM ring · hot from CPU cache
RAM utilization · working-set vs dataset
5.2 GB anonymous RAM (the pipe) · 5.4 GB resident incl. reclaimable page cache · 167.09GB on disk · RAM is the pipe, not the store
where the data was when the CPU read it
COLD on disk, straight off the NVMe
WARM in the RAM pipe (the conveyor ring)
HOT already in CPU cache
Nearly all hot and almost no cold, with a tiny resident working-set over a large
on-disk dataset, is the whole point: disk-capacity storage running at cache speed. RAM
here is a pipe, not the store. A normal engine only reaches this speed by first loading the
entire dataset into expensive RAM. This one keeps the truth on disk and streams only what the
query touches, so the resident bar above stays small while the reads stay hot.
Honest caveat: a networked cache pays a hop on every GET because it is a separate server, and here the compute runs on the data, so there is no hop. The additive point is durability, every key is durable on disk and survives a power loss with no RDB or AOF persistence tax, so this is cache-speed reads without the loss window, in the one engine that also serves graph, full-text and vectors.