Object demo: the blob and its graph in one GET path
You are looking at Bitcoin value-flow graph188.97M Bitcoin tx objects + metadata + value-flow links in one Semurg substrate. Ask it to serve a transaction object body, read its metadata, and walk its value-flow links 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 ask to walk value-flow links 3 deep, or change the hop count. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
the live Bitcoin value-flow graph, transactions and addresses linked by value-flows (prev-tx to tx to address), parsed straight off the P2P network · Bitcoin mainnet P2P (our own block-parser node, no bitcoind, no REST). Object bytes are runs of 64-byte containers, the metadata is more containers, and the links between objects are edges, all on one handle. Serving the body, reading the metadata, and walking the relationships is one engine, no separate metadata database, no separate search index. Measured live.
the object-storage leader
THREE SYSTEMS, ONE QUERY. The bytes live in the object store, the attributes in a separate metadata database, and the relationships in a separate search index, so a query that spans bytes and links is a cross-system stitch you keep in sync by hand.
semurg, one engine
ZERO separate systems, zero indexes. Body bytes, metadata and relationships live as one copy on one handle, so the body serve, the metadata read and the relationship walk are one GET path with nothing to keep coherent.
Three systems and the sync tax between them collapse into one.
Bitcoin transaction objects: raw tx bytes plus their metadata and value-flow links, 188.97M objects. Measured live on this box. Re-pull them over the Bitcoin P2P network and re-run it yourself.
5.2GB/s · object bytes served
8cores
536.9 MBbody served
103.23 msbody serve
122.7Kmetadata read
35.4Kmetadata reads/s
64.3Krelated objects
25.9Krelations/s
0separate systems
0indexes built
body serve = deep-QD io_uring region read (raw binary, no decode) · metadata = lock-free seqlock warm read off the RAM-ring · relationships = traversal #2 hops deep · all on one handle · sample related ids: 0, 1, 2, 3, 4
the answer
serve the object body, read its metadata, walk its links (2 hops)
leg of the object query
live result
object bytes served
536.9 MB
metadata containers read
122.7K
related objects reached
64.3K
sample related ids
0, 1, 2, 3, 4
all three legs on one handle, one copy of the data, folded live off disk
5.2GB/s
object body served off disk, plus metadata read and relationships walked in one pass
100xCommanding
bytes, graph and search in one engine
one copy, no second system to sync
hit-rate + reads/s · cold / warm / hot
cold 0.1%
warm 1.3%
hot 98.6%
cold 108.1M/s
warm 1.79B/s
hot 2.85B/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
4.7 GB anonymous RAM (the pipe) · 4.9 GB resident incl. reclaimable page cache · 171.24GB 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 framing: a single by-key blob GET on a warm object store is a wash, we do not claim to beat it at its own point-fetch. We show the real cold and warm number for each leg, never our hot against their cold. The win is not a faster point-GET, it is the second and third system that disappear.