pgvector

About pgvector

PostgreSQL extension for storing embeddings and running vector similarity search.

Best for: Teams that already operate a PostgreSQL database and want to add vector similarity search for RAG — keeping embeddings, metadata, and application data in one SQL database without adding a separate vector store service to the infrastructure stack.

Deployment: PostgreSQL extension installed via CREATE EXTENSION; available on self-hosted Postgres, Supabase, Neon, AWS RDS, Azure Database for PostgreSQL, and Google Cloud SQL

Skill level: Beginner to intermediate

Tradeoffs

Recall and throughput at scale (10M+ vectors) trail dedicated HNSW databases like Qdrant under equivalent hardware. PostgreSQL's MVCC transaction model adds overhead for high-throughput vector insert workloads compared to purpose-built vector stores. Metadata filtering uses SQL WHERE clauses rather than in-index filtering, which can degrade recall on highly selective predicates.

Related guides and resources

Explore step-by-step setup guides, comparisons, and stack recipes for this tool category.

Best for

Teams that already operate a PostgreSQL database and want to add vector similarity search for RAG — keeping embeddings, metadata, and application data in one SQL database without adding a separate vector store service to the infrastructure stack.

Why use it

pgvector eliminates the operational cost of a dedicated vector database for teams already on Postgres. Embeddings are stored as vector columns in regular Postgres tables, enabling SQL JOINs between vector search results and application data — a pattern that dedicated vector databases cannot express natively. For datasets under 1M vectors where HNSW or IVF_FLAT index delivers acceptable latency, pgvector avoids an entire service tier.

Key features

• Vector columns as native Postgres data types — embeddings JOIN directly with application tables in standard SQL queries
• HNSW and IVF_FLAT approximate nearest neighbor indexes with configurable m, ef_construction, and ef_search parameters
• Available on all major managed Postgres providers: Supabase, Neon, AWS RDS, Azure, Google Cloud SQL, and Timescale
• Exact and approximate nearest neighbor search with L2 distance, inner product, and cosine similarity distance operators

Tradeoffs

Recall and throughput at scale (10M+ vectors) trail dedicated HNSW databases like Qdrant under equivalent hardware. PostgreSQL's MVCC transaction model adds overhead for high-throughput vector insert workloads compared to purpose-built vector stores. Metadata filtering uses SQL WHERE clauses rather than in-index filtering, which can degrade recall on highly selective predicates.

Alternatives

• Chroma
• Qdrant
• Weaviate