Measured, published

One benchmark, stated in full.

A million postings, a hundred tenants and fifty concurrent reads, cold cache, on a disposable database. Four targets pass, one misses, three are unmeasured — and all of it is recorded rather than rounded.

Entity & exact reads

p9928.07 milliseconds

Target: 100 ms at p99. Pass.

Keyword recall

p9513.29 milliseconds

Target: 300 ms. Pass.

Keyword recall (tail)

p9915.14 milliseconds

Target: 1,000 ms. Pass.

Small durable write

p955.38 milliseconds

Target: 300 ms. Pass.

Run 30 September 2026 · PostgreSQL 18.6 + pgvector 0.8.6 · cold cache · disposable database. Your workload will differ.

Methodology

The fixture is the published scale, not a small cached demonstration. It is built by tools/benchmark/run.py --postings 1000000 on a disposable database, and the cache state is recorded.

FixtureValue
Postings1,000,000
Tenants100 (skewed: one workspace holds 100,000 postings, the rest share the remainder)
Largest workspace100,000 postings
Concurrent reads50
Build time20.5 s
Cache stateCold

What these numbers are — and are not

These are database and server timings for individual retrieval and write operations. They are not a claim about complete agent performance. End-to-end time includes the model, the client, the network and how the agent chooses to use the tools — none of which this benchmark measures.

The vector-arm miss

The exact cosine vector arm at 100,000 rows measured 363.93 ms p95 against a 150 ms target. It misses.

That is a pre-launch finding, not a regression. The hosted deployment at sbrain.app binds the in-boundary self-hosted embedder, so the vector arm runs there; a deployment with no bound provider runs keyword-only and the arm is unreachable. Today only facts are embedded — pages and playbooks stay keyword-only — so “hybrid recall” means the indexed facts, not every object.

The P1 vector arm is exact cosine over the materialised scoped set, with no global approximate index, so a 100,000-row workspace costs a full scan. Enabling semantic retrieval requires a documented evaluation first, and an approximate index is a later decision that must be compared against exact top-k with measured latency and memory.

Not measured

Three targets cannot be measured without a live embedding provider, so they are recorded as not measured — never as passing:

  • hybrid_recall_in_boundary
  • hybrid_recall_in_region
  • embedding_freshness

What we will measure next

Latency is not the product. The evidence that matters is whether the product does the job: whether it retrieves a paraphrased decision, returns the corrected revision after a change, and respects access boundaries. Those are the next published results, and the hybrid and vector numbers will be published with them once an embedding provider is bound.

Activation milestone. One authorised agent contributes a usable record, and a different authorised agent successfully retrieves it. That is the point at which the product has delivered value; sign-ups and connections are tracked along the way but are not treated as success on their own.

Read the tested integration matrix, or connect your agent.