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_search	pgContext recall	pgContext p50	pgvector recall	pgvector p50	speed-up
64	0.731	0.67 ms	0.750	2.56 ms	3.8×
128	0.810	0.94 ms	0.820	4.14 ms	4.4×
256	0.868	1.46 ms	0.870	7.09 ms	4.9×
512	0.910	2.44 ms	0.910	12.97 ms	5.3×

Table 2. Index build time (HNSW, 8-way parallel budget, 1.18M rows).
System	Build time	Relative
pgvector	50.3 s	1.00×
pgContext	88.0 s	1.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.