Search demo, index-free, full-text
You are looking at on-box passage corpuspublic passage corpus, stored as text in one Semurg substrate. Ask it to scan every passage for any term, no index 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 word or short phrase. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
A standard public passage corpus stored as text in the substrate. A query sweeps every passage with NO index, the moment data lands, any ad-hoc term, no ingest wait. Measured live.
the full-text search leader
CANNOT ANSWER IT. An inverted index must be built before the first query, minutes of ingest, and it can only answer the terms and fields it was told to index ahead of time.
semurg, one engine
Zero indexes built. Any ad-hoc term, the instant the corpus lands, by sweeping the raw text at memory bandwidth, on the same engine that also serves graph and vectors.
No index to build means nothing to wait for and nothing it cannot answer.
A passage corpus generated + scanned live on this box, index-free.
2.6Mrecords/s scanned
144.4Krecords scanned
2.6Mcontainer-reads/s
18.0Kcontain it
0.17GB/s
144.4K64-byte containers
0.01GB swept off disk
55.5 mslatency
0indexes built
query: "diabetes" · SIMD binary-pattern match over raw container bytes off disk (io_uring), no inverted index, no reassembly · the substring/regex workload an index can't answer
the answer
find every passage containing "diabetes"
18.0K passages contain "diabetes"
144.4K records swept
matched live off disk, no inverted index, no ingest wait
2.6Mrecords/s
index-free scan for "diabetes", 144.4K records swept, 18.0K contain it
100xCommanding
index-free, instant the moment data lands
the substring/regex query an index can't answer
hit-rate + reads/s · cold / warm / hot
cold 2.6M/s
warm 3.14B/s
hot 3.01B/s
cold disk sweep, one pass off disk, no re-read
RAM utilization · working-set vs dataset
5.2 GB anonymous RAM (the pipe) · 5.4 GB resident incl. reclaimable page cache · 9.2MB 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 pre-built inverted index, warm, on a single keyword it was told to index, can match or beat this scan on that one query. We do not claim to beat it there. The structural win is the ad-hoc case (any term, any substring or regex, the instant data lands, with nothing to build first) and that the same scan fuses with graph and vector in one pass on one substrate.