Benchmarks, with their conditions attached
Every number on this page carries the setup it was measured under. A benchmark without its conditions is marketing; the conditions are what let you decide whether the figure applies to your workload.
Verified 5 August 2026·Engine measurements
Query latency
~15,000 admitted passages
| Mode | p50 | p95 | p99 |
|---|---|---|---|
| Keyword BM25 term ranking | 2.1 ms | 2.6 ms | 2.8 ms |
| Semantic Vector similarity | 3.3 ms | 3.9 ms | 4.3 ms |
| Hybrid Both, fused by reciprocal rank | 4.6 ms | 6 ms | 6.5 ms |
~31,000 admitted passages
| Mode | p50 | p95 | p99 |
|---|---|---|---|
| Keyword | 2.4 ms | 2.9 ms | 3.4 ms |
| Semantic | 4.5 ms | 5.6 ms | 6 ms |
| Hybrid | 6.1 ms | 7.5 ms | 8 ms |
Method.Measured single-node, single-thread against a synthetic five-vertical corpus of ~15,000 admitted passages across ~2,000 hosts.
Doubling the admitted corpus from 15,000 to 31,000 passages moved keyword p50 by 0.3 ms. The curve is flat rather than logarithmic, which is the property that matters to you: the latency budget you measure today does not erode as the index grows underneath it.
Throughput
What is measured here, and what is not
Everything on this page is a serving measurement: what the engine does with a request you send, timed at the engine. That is deliberate. Index-time rates and the memory layout of the serving tier describe how we built the thing rather than what it does for you, and we do not publish them.
The figures that remain are the ones you would actually use to size a workload — and unlike an architecture diagram, you can reproduce them. The free tier is 10,000 requests a month with no card, which is enough to run your own latency harness against your own queries from your own region.
Conditions, always attached
Single-node, single-thread, on a corpus we describe by size and shape. A benchmark without its conditions is marketing.
Engine time, not wall clock
Your network round trip is additional and, from most places, larger than the query itself. Budget for it before optimising anything here.
A small corpus
15,000–31,000 passages is not web scale, and we will not restate these as if it were. The scaling curve is evidence of a shape, not proof at a thousand times the size.
What the latency budget looks like
For an agent making several retrieval calls per turn, search latency is a real part of the user-perceived response time — and the only part you can control without changing models.
- Keyword p502.1 ms
- Semantic p503.3 ms
- Hybrid p504.6 ms
- Hybrid p996.5 ms
Frequently asked questions
What corpus were these figures measured on?
A synthetic five-vertical corpus of roughly 15,000 to 31,000 admitted passages across about 2,000 hosts, running single-node and single-thread. That is a small corpus, and we state it rather than implying the numbers were taken at web scale.
Will latency hold as the index grows?
The measured evidence is that doubling the corpus moved keyword p50 by 0.3 ms — from 2.1 to 2.4. The curve is flat rather than logarithmic, which is the property that matters to you. It is evidence of the shape, not proof at a thousand times the scale, and we will not claim otherwise until we have measured it.
Why are these serving figures only?
Because they are the only ones you can act on. Index-time rates and the resident-memory layout describe our pipeline rather than your request, and we no longer publish them — how the index is built and served is the part of this business worth protecting. Latency, throughput, filter semantics and coverage transparency all remain published in full.
What p99 should I design for?
Use the p99 column, not the median, and add your own network round trip — these are server-side figures measured at the engine. For a European caller the round trip typically dominates the query itself, which is worth knowing before you optimise the wrong half.
Do you publish query-quality benchmarks against competitors?
Not yet. Retrieval-quality comparisons across providers are extremely sensitive to query set selection, and a benchmark we designed and ran ourselves would deserve the scepticism it got. The figures on this page are all engine measurements, which are reproducible in a way that a quality shootout is not. The free tier is 10,000 requests a month precisely so you can run your own.
Measure it yourself
The free tier is enough to run your own latency test against real queries. That is a better benchmark than ours, because it uses your workload.