Relational HTAP demo: OLTP and OLAP on one copy
You are looking at Bitcoin value-flow684.24M value-flow edges · one copy, no ETL in one Semurg substrate. Ask it to run a warehouse aggregation, or a single-row lookup 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 analyze for the aggregation, or lookup for the point read. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
The live Bitcoin value-flow stored as value-flow edges in the substrate. The same single copy answers a warehouse-style full-table aggregation AND a point transactional lookup. No ETL, no second engine, no pre-built index. Measured live.
the row-store + warehouse stack
TWO ENGINES AND AN ETL. The point read lives in a transactional row store, the big aggregation lives in a separate columnar warehouse, and a nightly pipeline copies between them, so the warehouse is always one ETL cycle stale.
semurg, one copy
One copy, zero ETL. The full-table aggregation and the single-row lookup hit the exact same durable rows, the instant the data lands, with no second system to keep in sync.
We do not win the scan. We delete the warehouse, the ETL, and the staleness window between them.
The live Bitcoin value-flow graph, 684.24M edges, aggregated in place. Measured live on this box.
1.21Brows/s aggregated (warm)
89.2Mrows/s cold
1.21Brows/s warm
4.39Brows/s hot
2.62Brows folded
8cores
29.32 scold latency
0ETL steps
full-table aggregation · cold 29.32 s io_uring QD16 · warm 6.6 ms resident · hot 400.0 µs cache-resident · no copy into a warehouse
the answer
warehouse-style aggregation over the whole value-flow table
the aggregation
live result
rows folded
2.62B
cold rows/s (first touch off disk)
89.2M
warm rows/s (resident)
1.21B
hot rows/s (cache-resident)
4.39B
folded straight on the transactional rows, no copy into a warehouse, no ETL
96.0 µsper single-row lookup (median)
3row id
9point reads
10.4Klookups/s
0live hits
0network hops
seqlock point read · durable on disk (disk=truth) · same copy as the aggregation above
the answer
single-row transactional lookup (row id 3)
the point read
live result
row id read
3
median per lookup
96.0 µs
point reads sampled
9
lookups/s
10.4K
seqlock read off the RAM-ring, durable on disk, same copy as the aggregation
96.0 µsper lookup
single-row transactional point read (median of 9), same copy as the aggregation
~50-100x the row-store point read
no network hop, durable on disk
hit-rate + reads/s · cold / warm / hot
cold 103.1M/s
warm 501.0K/s
hot 435.6K/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 · 167.8GB 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.
A purpose-built columnar warehouse can still out-scan us on a single pre-modeled aggregation it was laid out for, and we never claim our cold beats their hot. The analytical sweep and the transactional lookup hit the one durable copy, the moment the data lands, and the same substrate also serves graph, full-text and vectors.