pgvector for RAG: Capabilities and Limits

pgvector is an open-source Postgres extension for vector similarity search. For RAG its draw is simple: you keep embeddings, metadata, and transactional data in one database. Its main ceilings are the same ones Postgres already has at scale: approximate indexes trade recall for speed, and very large vector workloads still push you toward a purpose-built engine.

What is pgvector, and when is Postgres the right place for vector search?

pgvector adds vector columns and vector similarity operators to Postgres, so vectors live beside the rows they describe instead of in a second database. As of July 2026, the project’s own README says pgvector supports exact and approximate nearest-neighbor search, single-precision, half-precision, binary and sparse vectors, and L2, inner product, cosine, L1, Hamming, and Jaccard distance operations. It supports Postgres 13 and later.

That makes pgvector a strong RAG fit when the same system already needs SQL joins, ACID transactions, backups, and point-in-time recovery on the non-vector data. If your application already stores users, documents, permissions, and business records in Postgres, pgvector lets retrieval live beside them rather than across a second operational boundary. If you only need raw vector retrieval at very large scale, the trade changes, and that broader decision is at which vector database should you use.

How does pgvector balance exact search, HNSW, and IVFFlat?

pgvector does exact nearest-neighbor search by default, and the README says that default path provides perfect recall. Approximate search is opt-in. The two main choices are HNSW and IVFFlat, and the trade is explicit in the project docs rather than hidden behind marketing.

HNSW has a better speed-recall trade-off, but the README says it builds more slowly and uses more memory. IVFFlat builds faster and uses less memory, but its query quality is weaker than HNSW at the same speed target. That means pgvector does not pretend one index wins everywhere. It gives you an exact baseline, then two approximate paths with different costs. The mechanism details belong to HNSW and IVF and flat indexes. On this profile page, the important point is narrower: pgvector’s speed comes from index choice, and index choice always moves recall, memory, or build time.

What are pgvector’s capabilities and limits, side by side?

pgvector is easiest to understand when each strength is paired with the ceiling that comes with it. That is the difference between a useful profile and a feature list.

The row most teams miss is filtering. pgvector’s own README says approximate indexes apply filters after the index scan, so a query can return fewer matching rows than you expected. That is not a bug in your app. It is part of the trade-off you bought when you switched from exact search to ANN.

Where does pgvector hit ceilings in production?

pgvector hits its ceilings in workload shape, not in the install command. The first ceiling is filtered ANN. The README says that with approximate indexes, filtering happens after the index scan; if the filter is selective, you may get fewer qualifying rows back unless you scan more of the index. Starting with pgvector 0.8.0, iterative index scans were added to keep scanning until enough matches are found or limits are hit.

The second ceiling is memory and maintenance. HNSW uses more memory than IVFFlat, and the README says HNSW vacuuming can take a while, recommending reindexing first to speed it up. The third ceiling is vector width. Stored vectors can be wider than indexed vectors, but the common `vector` index path still caps indexed dimensions at 2,000.

Each vector takes: 4 * dimensions + 8 bytes

# worked example: 384-dimensional float32 embedding
4 * 384 + 8 = 1,544 bytes per vector

# one million such vectors
1,544 * 1,000,000 ≈ 1.54 GB before index overhead

That number is small enough for prototypes and moderate corpora, but it stops being abstract once the document count rises. If your RAG system needs high-cardinality metadata filters, very large ANN indexes, and heavy concurrent query load at the same time, Postgres can still do the job, but it stops being the easy default. That is the point where the broader vector-database decision matters more than the extension itself.

Is pgvector free, and how does it compare to Weaviate and Pinecone?

pgvector is open-source and self-hosted because it is a Postgres extension. There is no separate pgvector control plane to buy. Managed experiences usually arrive through hosted Postgres providers such as Supabase, not through pgvector as a standalone service.

Against nearby alternatives, the fit is clear. Weaviate gives you more vector-native features inside one dedicated system, including hybrid retrieval and database-level multi-tenancy. Pinecone removes most database operations entirely by giving you a managed vector service. pgvector wins when the application already needs relational joins, transactions, and one database for everything. It loses when the vector workload grows large enough that the Postgres convenience no longer offsets the search-engine trade-offs. The scored verdict across Weaviate, Pinecone, Qdrant, Milvus, FAISS, Redis, and pgvector is at which vector database should you use.