pgvector is the most popular vector extension for PostgreSQL, but the default configuration is not production-ready. Without proper indexing, query planning, and scaling patterns, pgvector queries degrade rapidly as your vector count grows. Here is the production guide for pgvector: indexing strategies, performance tuning, and scaling patterns that achieve sub-50ms retrieval at million-vector scale.
Index Selection
pgvector supports three index types: IVFFlat (inverted file with flat quantisation) — fast to build, moderate query performance, good for datasets under 1M vectors. HNSW (Hierarchical Navigable Small World) — slower to build, faster queries, better for datasets over 1M vectors. Flat (exact search) — slowest queries, exact results, only for small datasets or validation. For production RAG: use HNSW for datasets over 100K vectors, IVFFlat for datasets under 100K vectors. HNSW consistently achieves sub-50ms queries at million-vector scale.
HNSW Configuration
HNSW has two key parameters: ef_construction (build-time quality, default 64) and m (connections per node, default 16). Higher values improve recall but increase build time and index size. Production recommendations: ef_construction=128, m=24 for high-recall applications (customer support, healthcare). ef_construction=64, m=16 for moderate-recall applications (content recommendation, search). Monitor recall by comparing HNSW results against exact search on a sample — target 95%+ recall.
Note
HNSW index build time for 1M vectors: ~10 minutes with ef_construction=128, m=24. This is a one-time cost — the query performance improvement is permanent.
Scaling Patterns
For scale beyond a single PostgreSQL instance: read replicas (distribute queries across multiple replicas), partitioning (partition the chunks table by document or tenant), connection pooling (PgBouncer in transaction mode for high-concurrency), and caching (cache frequent query results in Redis). For scale beyond 10M vectors: consider sharding across multiple PostgreSQL instances, each handling a subset of the document collection. The key: pgvector scales horizontally through PostgreSQL's native replication and partitioning — no custom sharding required.
Conclusion
pgvector is production-ready with proper configuration: HNSW indexing, tuned parameters, and PostgreSQL's native scaling patterns. For most RAG deployments (under 10M vectors), pgvector on a single PostgreSQL instance with read replicas provides sub-50ms retrieval at production scale.
Key Takeaways
- HNSW for 100K+ vectors; IVFFlat for under 100K — HNSW achieves sub-50ms at million-vector scale
- Production HNSW config: ef_construction=128, m=24 for high recall; 64/16 for moderate recall
- Scale via PostgreSQL native features: read replicas, partitioning, connection pooling
- Monitor recall: compare HNSW results against exact search on a sample — target 95%+ recall
- pgvector scales to 10M+ vectors with standard PostgreSQL scaling patterns — no custom sharding needed