pgvector benchmarks: the real numbers

250,000 × 1536-dim vectors · HNSW m=16 ef_construction=64 cosine · index build 889s · load generator cpx32 (4 vCPU)

Highlighted row ≈ recall@10 0.90 to 0.95, the usual production operating band.

250,000 × 1536-dim vectors · HNSW m=16 ef_construction=64 cosine · index build 293s · load generator cpx32 (4 vCPU)

Highlighted row ≈ recall@10 0.90 to 0.95, the usual production operating band.

250,000 × 1536-dim vectors · HNSW m=16 ef_construction=64 cosine · index build 122s · load generator cpx62 (16 vCPU)

Highlighted row ≈ recall@10 0.90 to 0.95, the usual production operating band.

250,000 × 1536-dim vectors · HNSW m=16 ef_construction=64 cosine · index build 76s · load generator cpx62 (16 vCPU)

Highlighted row ≈ recall@10 0.90 to 0.95, the usual production operating band.

cpx42 · 8 vCPU / 16 GB · ~6 GB HNSW index built in 544s (9 min) and held hot in RAM. At bigger N the same ef_search gives lower recall (more true neighbours to find), so read recall per row.

# re-validated 10 August 2026

In August we changed the fleet's connection and memory defaults: every dedicated node now runs PgBouncer with 20 to 40 transaction slots per database (500 to 10,000 pooled client connections by tier) and a tighter work_mem of 8 to 32 MB. Because those settings could plausibly move the numbers above, we re-provisioned all four tiers from scratch and re-measured with the same harness. Like-for-like operating points came back within shared-vCPU run variance, so the July tables stand. Two additional findings, both measured:

• - work_mem A/B, zero difference. Filtered vector queries with hnsw.iterative_scan = relaxed_order at 10% and 1% selectivity, measured order-interleaved after warmup at both the new and the old work_mem on every tier: recall@10 exactly equal, p50 and p95 within noise. The scan-memory bound is never reached at these dataset sizes.
• - Past the pool, queries queue instead of failing. We ran double each tier's transaction slots (80 clients on Scale's 40). Zero connection errors; backends pin at the cap and the extra clients wait, trading p50 for admission.

New measurements the July run didn't cover (pgvector 0.8.6):

A 500k × 1536 index (~3 GB) builds and serves hot on Growth (8 GB); Scale's 1M row above is the same large-index claim as July, now also measured at 40 and 80 clients. Read recall per row, as always: the 4,629 QPS row is a low-recall operating point shown for the queueing behavior, not a headline.

# methodology

• - Data: Gaussian-mixture clusters (structure dominates, not uniform random noise). Queries are small perturbations of real points, giving a well-defined recall@10 against exact brute-force KNN.
• - Index: pgvector 0.8.5 HNSW, m=16, ef_construction=64, cosine. PostgreSQL 17.10.
• - Tuning: each node uses Rivestack's per-size defaults: shared_buffers 25% RAM, effective_cache_size 75%, parallel workers = vCPU, random_page_cost 1.1. The July tables ran work_mem = RAM/64; since August the default is 8 to 32 MB by tier, and the re-validation above measured no difference between the two.
• - ef_search is set with SET LOCAL inside each query's transaction (a plain session SET is silently dropped by PgBouncer transaction pooling).
• - Client path: a separate same-datacenter VM (≥ the DB's core count) over TLS. Measured network floor 0.34 to 0.51 ms per round-trip. Throughput uses one process per client (no GIL).
• - What we don't claim: peak QPS and minimum p50 at the same time; competitor numbers we didn't run; a single number for all regions.

# reproduce it

On a same-region VM with Python, numpy and psycopg2:

# harness: https://github.com/Rivestack/pgvector-bench
export DSN='postgres://USER:PASS@YOUR-DB.eu.db.rivestack.io:6432/db?sslmode=verify-full'
export N=250000 EFS='10,20,40,80,120,200' CONCS='1,4,8,16' DUR=12
python3 bench.py
# prints: ef | recall@10 | per-concurrency QPS/p50/p95/p99

Point it at your own database and dataset, and the numbers you get are the numbers you get. That's the whole idea.