Time-series demo: scrape, store and range-query in one engine
You are looking at Binance live market streamsamples as time-ordered 64-byte containers, durable on disk in one Semurg substrate. Ask it to RANGE a time window and bucket it, cold off disk then warm resident 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 RANGE, or bucket a different time window. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
A public metrics series stored as a time-ordered run of 64-byte containers, durable on disk. A range query is a time-window scan with bucketed aggregation, run in place. No second database, no rollup index to build, no compaction. Cold and warm rates, measured live.
the metrics-TSDB leader
INGEST, THEN COMPACT. A purpose-built TSDB must build a rollup/downsample index and run compaction before its pre-aggregated query is fast, all in a separate system you ingest into first.
semurg, one engine
Zero indexes built. The scrape lands as containers and the same substrate range-queries them in place, no rollup, no compaction, then fuses with graph, full-text and vectors in one pass.
The whole ingest-then-compact tax, and the second database, is gone.
A public metrics series. Measured live on this box. Download it and re-run it yourself.
107.1Msamples/s · cold range scan
2.4Msamples in window
60time buckets
2.08Bsamples/s warm
6853.0MB/s cold
22.0 mscold latency
0indexes built
cold: io_uring/O_DIRECT region scan · warm: seqlock RAM-ring across 8 cores · durable on disk (disk=truth) · no compaction, no rollup index
the answer
RANGE 2.4M samples into 60 time buckets
the range-query answer
live result
samples in the window
2.4M
time buckets computed
60
warm samples/s (resident fold)
2.08B
rollup indexes built
0
bucketed in the same pass that read the samples, no pre-rolled index, no compaction
107.1Msamples/s
RANGE over 2.4M samples, cold io_uring scan
100xCommanding
collapse: scrape, store and range-query in one substrate
no rollup index, no compaction, no second database
hit-rate + reads/s · cold / warm / hot
cold 107.1M/s
warm 2.08B/s
hot 4.87B/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.1 GB anonymous RAM (the pipe) · 5.3 GB resident incl. reclaimable page cache · 1.4GB 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.
The win here is collapse, not raw scan speed. A purpose-built metrics store with a pre-rolled, downsampled index answers its one pre-aggregated query fast, but the index has to be built first and lives in a separate engine. Here there is no second system, no ingest-then-compact tax, and no index to build before the first query: the scrape lands as containers and the same substrate range-queries them in place, then fuses with graph, full-text and vectors in one pass. We show cold and warm side by side and never compare a warm path to anyone's cold one.