How Brainy compares
vs pgvector HNSW — index-level p50/p99 latency, same host (bxl9000: Ryzen 9 7950X3D / NVMe), same dataset + query workload:
In this section
vs pgvector HNSW — index-level p50/p99 latency, same host (bxl9000: Ryzen 9 7950X3D / NVMe), same dataset + query workload:
10 K: brainy p50 0.048 ms vs pgvector p50 0.865 ms → 18.02×
100 K: brainy p50 0.041 ms vs pgvector p50 0.536 ms → 13.07×
1 M: brainy p50 0.148 ms vs pgvector p50 1.081 ms → 7.30×
Brainy stays sub-millisecond at p99 even at 1 M (0.309 ms p99 brainy vs 1.604 ms p99 pgvector); pgvector crosses 1 ms p99 at this scale.
Read this as latency, not a blanket "faster": a latency ratio is only meaningful when both engines sit at the same recall. The recall-matched comparison on real-manifold data (SIFT/BIGANN) is being measured in the library A/B; treat these as brainy's index-level latency headroom on this reference host, not an end-to-end product claim.
Source:
scripts/verify-vs-pgvector.mjs· result JSON indocs/verification/
Brainy's acceleration of Brainy (isolated-operation micro-benchmarks): 5.2× geometric mean across 15 isolated operations on bxl9000 (Embedding 2.8× · Infrastructure 7.8× · Search 25.2× · Data ops 7.3×). This is per-operation acceleration measured in isolation — not an end-to-end
find()speedup. The end-to-end library A/B (brainy-alone vs brainy+brainy through the publicfind()path, recall@10 on SIFT) is in progress; that table will be the headline product number.
Where brainy genuinely leads
Data sovereignty — the whole design, not a deployment option
Every managed vector database holds your data on someone else's machines, meters what you store, and phones home by design. Brainy is the opposite by construction, not by configuration:
Your machines, your files. The store is files on disks you own. There is no hosted tier, no control plane, no cloud dependency of any kind.
An open format with an MIT reader. Anything Brainy writes, Open Brainy reads — your data is legible without us, forever. The exit door is code, not a promise.
No telemetry. None. Not opt-out, not opt-in. License verification is offline (Ed25519, checked locally), and nothing in the engine ever contacts Soulcraft — a test in the suite fails if that ever changes.
Nothing is metered. Licensing is flat and org-sized; the engine never counts your data on anyone's behalf, including ours.
Compliance teams call this data sovereignty and data residency. Here it is simply how the engine works — there is no mode in which it works otherwise.
Most vector databases can do vector ANN. A few can filter by metadata. Almost none can hop graph edges. None can do all three in a single sub- millisecond query AND support point-in-time reads. Brainy is the only system in that category:
Vector ANN | Metadata filter | Graph hop | Time-travel | Triple find() composition | |
|---|---|---|---|---|---|
Brainy 3.0 | ✅ | ✅ | ✅ | ✅ | ✅ |
pgvector | ✅ | ✅ (SQL) | partial (SQL JOIN) | ❌ | partial |
Qdrant | ✅ | ✅ | ❌ | ❌ | ❌ |
Milvus | ✅ | ✅ | ❌ | ❌ | ❌ |
Weaviate | ✅ | ✅ | weak | ❌ | ❌ |
Pinecone | ✅ | ✅ | ❌ | ❌ | ❌ |
FAISS | ✅ | ❌ | ❌ | ❌ | ❌ |
Triple-find composition at 1 M — per-stage substrate latency: LSM filter 16 µs + graph BFS 16 µs + DiskANN 194 µs + JS-side intersection, composing to p50 ≈ 0.230 ms on bxl9000. Source: scripts/verify-triple-find.mjs.
Honesty note (being re-validated): this composition was measured on a synthetic corpus, where random vectors are near-orthogonal under cosine (concentration of measure) so the vector leg's recall is ~0 and the composed result set is near-empty. The per-stage latencies are valid (each substrate did its work), but the end-to-end triple-find latency and recall are being re-measured on real-manifold data (SIFT/BIGANN). Treat 0.230 ms as the substrate-composition ceiling, not the validated end-to-end number. Brainy 8.0 also pushes the intersection into native primitives.
At a Glance
Category | Avg Speedup | What it covers |
|---|---|---|
Embedding | 2.8x | Real ML model inference (all-MiniLM-L6-v2) |
Data Operations | 7.3x | Adding, reading, and deleting entities |
Search | 25.2x | Finding entities by meaning, filters, and similarity |
Graph | 1.3x | Querying relationships between entities |
Neural | 1.9x | AI-powered neighbors and clustering |
Scale Ceiling
The numbers above measure speedup at the 200-entity tier — the "make my queries faster" story. Brainy also moves the scale ceiling itself: with DiskANN engaged, a single Brainy instance reaches workloads that were previously single-machine impossible.
PROJECTED — design targets, not measured. The table below is extrapolated from algorithm math (Vamana / PQ memory + latency models). Measured numbers at 100M and 1B on real hardware ship in
docs/verification-report.mdas part of Piece 9 of the brainy 3.0 release. PerCLAUDE.md, perf claims without aMEASUREDcitation must carry aPROJECTEDlabel until verified.
Workload | Brainy alone | Brainy + Brainy (HNSW) | Brainy + Brainy (DiskANN) |
|---|---|---|---|
1 M vectors @ 384-dim | OK, ~1 GB RAM | OK, ~1 GB RAM, 25× faster search | OK, ~0.5 GB RAM, sub-ms search |
10 M vectors | OK, ~15 GB RAM, slow build | OK, ~10 GB RAM | OK, ~3 GB RAM, 1–3 ms search |
100 M vectors | Out of practical reach | OK if you have 100+ GB RAM | OK on a 32 GB box, 2–5 ms search |
1 B vectors | Not possible (1.5 TB RAM) | Not possible (1.5+ TB RAM) | OK on a 64 GB box, 5–10 ms search |
DiskANN auto-engages when storage is local and a stable idMapper is available — see docs/diskann.md. Cloud-storage adapters stay on HNSW transparently.
Embedding consistency: max element-wise diff = 1.43e-7, avg = 2.64e-8 (WASM and native produce equivalent vectors)
Same results, just faster. Brainy accelerates Brainy without changing any answer: native output matches the JavaScript baseline byte-for-byte, enforced by a 104-test cross-language parity suite (tokenization, value normalization, string collation, SQ8 distance, top-K ranking, roaring/msgpack). See Brainy Performance → Cross-Language Consistency.
Detailed Results
Embedding
What it does | WASM | Native Rust | Speedup |
|---|---|---|---|
Engine initialization | 192 ms | 115 ms | 1.7x |
Embed one sentence | 116 ms | 47 ms | 2.4x |
Embed 1 sentence (batch path) | 116 ms | 55 ms | 2.1x |
Embed 10 sentences | 1173 ms | 330 ms | 3.6x |
Embed 20 sentences | 2371 ms | 611 ms | 3.9x |
Embed 50 sentences | 6050 ms | 1577 ms | 3.8x |
Data Operations
What it does | Brainy | + Brainy | Speedup |
|---|---|---|---|
Store one entity | 21 ms | 3.0 ms | 7.0x |
Store 20 entities at once | 1384 ms | 110 ms | 12.6x |
Retrieve one entity | 0.001 ms | 0.001 ms | 1.3x |
Remove and re-insert | 113 ms | 4.5 ms | 25.0x |
Search
What it does | Brainy | + Brainy | Speedup |
|---|---|---|---|
Search by meaning | 21 ms | 0.4 ms | 50.8x |
Search by fields | 1.9 ms | 0.018 ms | 108.3x |
Find similar items | 0.3 ms | 0.1 ms | 2.9x |
Graph
What it does | Brainy | + Brainy | Speedup |
|---|---|---|---|
Query relationships | 0.011 ms | 0.008 ms | 1.3x |
Neural
What it does | Brainy | + Brainy | Speedup |
|---|---|---|---|
Nearest neighbors | 0.001 ms | 0.001 ms | 1.9x |
Auto-cluster items | — | — | skipped |
Embedding Throughput (batch of 50)
Engine | Texts/sec | ms/text |
|---|---|---|
WASM | 8 | 121.0 |
Native Rust | 32 | 31.5 |
Methodology: Infrastructure operations measured 20 times after 3 warmup runs; embedding operations measured 10 times after 2 warmup runs. Reported value is the median. Infrastructure benchmarks use a lightweight hash-based embedding to isolate acceleration from model differences. Embedding benchmarks use the real all-MiniLM-L6-v2 model (384-dim). "Speedup" is the geometric mean of per-operation ratios within each category.