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:

Vector ANN

Metadata filter

Graph hop

Time-travel

Triple find() composition

Cor 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. 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.

Workload

Brainy alone

Brainy + Cor (HNSW)

Brainy + Cor (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. 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

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

+ Cor

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

+ Cor

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

+ Cor

Speedup

Query relationships

0.011 ms

0.008 ms

1.3x

Neural

What it does

Brainy

+ Cor

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.