How Cor compares

vs pgvector HNSW — index-level p50/p99 latency, same host (bxl9000: Ryzen 9 7950X3D / NVMe), same dataset + query workload:

• 10 K: cor p50 0.048 ms vs pgvector p50 0.865 ms → 18.02×
• 100 K: cor p50 0.041 ms vs pgvector p50 0.536 ms → 13.07×
• 1 M: cor p50 0.148 ms vs pgvector p50 1.081 ms → 7.30×

Cor stays sub-millisecond at p99 even at 1 M (0.309 ms p99 cor 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 cor's index-level latency headroom on this reference host, not an end-to-end product claim.

Source: scripts/verify-vs-pgvector.mjs · result JSON in docs/verification/

Cor'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+cor through the public find() path, recall@10 on SIFT) is in progress; that table will be the headline product number.

Where cor genuinely leads

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. Cor is the only system in that category:

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

Scale Ceiling

The numbers above measure speedup at the 200-entity tier — the "make my queries faster" story. Cor 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.md as part of Piece 9 of the cor 3.0 release. Per CLAUDE.md, perf claims without a MEASURED citation must carry a PROJECTED label until verified.

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. Cor 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 Cor Performance → Cross-Language Consistency.

Detailed Results

Embedding

Data Operations

Search

Graph

Neural

Embedding Throughput (batch of 50)

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.