A recommendation engine team came to us after their pgvector similarity searches were taking 800ms at the 99th percentile on a 5M-vector table. After upgrading to pgvector 0.8 and retuning their HNSW index parameters, p99 dropped to 35ms — without adding hardware. The 0.8 release rewrote key parts of the HNSW build algorithm and added distance function improvements that compound significantly at scale.
This guide covers what changed in pgvector 0.8, how to upgrade safely, and the tuning parameters that matter most for production vector search workloads.
- pgvector 0.8 delivers faster HNSW index builds — up to 40% faster than 0.7 at scale.
- New
halfvectype stores 16-bit floats, halving storage for high-dimensional vectors. - Improved IVFFlat recall at the same
listssetting — recalibrate after upgrade. - Reindex HNSW indexes after upgrading for the build algorithm improvements to take effect.
What Changed in pgvector 0.8
halfvec: Half-Precision Vector Storage
pgvector 0.8 introduces the halfvec type, storing vectors as 16-bit floats instead of 32-bit. For OpenAI's 1536-dimension embeddings, this halves storage from 6.1KB to 3.1KB per vector:
-- Create a halfvec column (16-bit floats, half the storage)
ALTER TABLE documents ADD COLUMN embedding_half halfvec(1536);
-- Populate from existing float4 vectors
UPDATE documents SET embedding_half = embedding::halfvec;
-- Build HNSW index on halfvec column
CREATE INDEX ON documents USING hnsw (embedding_half halfvec_cosine_ops)
WITH (m = 16, ef_construction = 64);For most embedding models, halfvec recall is within 1-2% of float4 — the precision loss is negligible for approximate nearest neighbor search. Benchmark your specific model before migrating production data.
Faster HNSW Index Builds
The HNSW build algorithm in 0.8 is significantly faster, especially for high-dimensional vectors and large datasets. Benchmarks on 5M 1536-dim vectors show 40% faster build times compared to 0.7:
-- Optimal HNSW build config for high-dimensional vectors
SET max_parallel_maintenance_workers = 7;
SET maintenance_work_mem = '8GB';
CREATE INDEX CONCURRENTLY ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 128);Distance Function Improvements
pgvector 0.8 optimizes the inner product (<#>) and L2 (<->) distance calculations using SIMD instructions where available. On modern CPUs (AVX-512), this delivers 20-30% faster distance computations during query time.
Upgrading pgvector
apt-get install postgresql-16-pgvector=0.8.0
psql -c "ALTER EXTENSION vector UPDATE TO '0.8.0';"
psql -c "SELECT extversion FROM pg_extension WHERE extname = 'vector';"After upgrading, REINDEX your HNSW indexes to get the new build algorithm improvements. Existing indexes built with 0.7 will continue to work but won't benefit from the faster build path until rebuilt.
-- Reindex HNSW indexes (use CONCURRENTLY to avoid locking)
REINDEX INDEX CONCURRENTLY idx_documents_embedding;Tuning HNSW for Production
| Parameter | Default | High-Recall Setting | Low-Latency Setting |
|---|---|---|---|
| m | 16 | 32-48 | 8-12 |
| ef_construction | 64 | 128-256 | 32-64 |
| hnsw.ef_search | 40 | 100-200 | 20-40 |
-- Set ef_search at query time
SET hnsw.ef_search = 100;
SELECT id, content, embedding <=> query_embedding AS distance
FROM documents ORDER BY embedding <=> query_embedding LIMIT 10;- The
halfvectype halves storage for high-dimensional embeddings with minimal recall loss — worth evaluating for any vector table over 1M rows. - Reindex HNSW indexes after upgrading to pgvector 0.8 — old indexes work but miss the build algorithm improvements.
- Increase
maintenance_work_memandmax_parallel_maintenance_workersbefore large HNSW builds. - Tune
hnsw.ef_searchat query time based on your recall vs latency requirements.
Working with JusDB on Vector Search
JusDB designs and optimizes pgvector deployments for RAG pipelines, recommendation systems, and semantic search. We handle index sizing, query tuning, and hybrid search architectures combining pgvector with PostgreSQL full-text search.
