Reproducible benchmark · recognized dataset

pgContext versus pgvector on GloVe-100-angular

Approximate nearest-neighbor search, 1,183,514 × 100-dimensional vectors, cosine distance

Dataset
ann-benchmarks glove-100-angular — 1,183,514 train, 10,000 test, 100 dims
Ground truth
Dataset-provided exact neighbors (not self-computed)
Metric
Angular / cosine · recall@10
Deployment
pgContext and pgvector in the same PostgreSQL 17 container
Index
HNSW, m = 16, ef_construction = 64, 8-way parallel build (both engines)
Hardware
Apple M4 Pro · PostgreSQL 17 · pgvector 0.8.5 · NEON kernels
Date
2026-07-20 · single trial, warm cache, single client

At every search setting the two engines return the same recall — both trace one curve from 0.73 to 0.91 — but pgContext answers each query 3.8 to 5.3× faster. The gap widens with search effort: at ef_search 512, pgContext holds 0.910 recall@10 at 2.44 ms where pgvector reaches the same recall at 12.97 ms.

pgContext pgvector points labeled by ef_search
Figure 1. Latency–recall frontier (log latency axis). Lower and further right is better. The curves share the same horizontal positions — equal recall — while pgContext sits far below pgvector at every point.
pgContext pgvector
Figure 2. Query latency (p50) against search effort. pgvector's latency climbs steeply with ef_search; pgContext stays low, so the speed advantage grows as recall targets rise.

Results

Table 1. Recall@10 and median (p50) query latency at each ef_search.
ef_searchpgContext recallpgContext p50pgvector recallpgvector p50speed-up
640.7310.67 ms0.7502.56 ms3.8×
1280.8100.94 ms0.8204.14 ms4.4×
2560.8681.46 ms0.8707.09 ms4.9×
5120.9102.44 ms0.91012.97 ms5.3×
Table 2. Index build time (HNSW, 8-way parallel budget, 1.18M rows).
SystemBuild timeRelative
pgvector50.3 s1.00×
pgContext88.0 s1.75×

pgvector builds the index faster; pgContext trades that for the query-time advantage above. Build throughput is an area of active work.

Both systems ran inside the same PostgreSQL container, queried over the same connection, on identical vectors with identical HNSW settings. The only thing that changes between the two columns is the index engine — so the speed difference comes from the engines themselves, not the test setup.

Method & reproducibility

  • Recall is measured against the dataset's shipped ground-truth neighbors; each query's returned top-10 ids are intersected with the true top-10.
  • Latency is per-query wall-clock (p50 of 10,000 queries), JIT and parallel-gather disabled, warm cache, after a warmup pass; each query plan is verified to use the HNSW index.
  • Single trial on an Apple M4 Pro with NEON distance kernels; absolute numbers are machine-specific. x86 AVX2 kernels exist but are not yet performance-measured.
  • Harness, Dockerfile, and the archived result JSON: benchmarks/pgvector_comparison/. Three-system comparison including Qdrant: pgcontext-vs-pgvector-vs-qdrant.html.