pgvector

What It Is

pgvector adds vector similarity search (cosine, L2, inner product) to PostgreSQL. You store embeddings in the same database as your application data, query them with SQL, and use HNSW or IVFFlat indexes for fast approximate nearest-neighbour search. Version 0.8.2 (March 2026) fixes a buffer overflow in parallel HNSW builds (CVE-2026-3172).

Why It Matters

pgvector is Proven because it solved the right problem: most teams already run Postgres, and adding vector search without another database in the stack eliminates operational complexity. The pgvectorscale benchmarks (Timescale) showed 471 QPS versus Qdrant's 41 QPS at 99% recall on 50M vectors — competitive performance without a separate system to manage.

The practical appeal is obvious. One connection string. One backup strategy. One set of access controls. For teams building RAG applications with millions (not billions) of vectors, pgvector is the path of least resistance.

Key Developments

• Mar 2026: pgvector 0.8.2 fixes buffer overflow with parallel HNSW index builds (CVE-2026-3172).
• Late 2025: pgvector 0.8.0 adds iterative index scans to prevent overfiltering and improve query performance with filters.
• Ongoing: Supported on all major managed Postgres services: AWS RDS, Google Cloud SQL, Azure, Supabase, Neon, Timescale.

What to Watch

The scalability ceiling is where pgvector's story ends and dedicated vector databases begin. If your dataset grows past tens of millions of vectors or you need horizontal scaling for vector search, you'll need to evaluate alternatives. Watch for pgvector's filtered search improvements — combining vector similarity with relational filters is still rougher than what dedicated databases like Weaviate provide out of the box.