pgvector vs Qdrant vs Pinecone for RAG (2026)

Comparison

	pgvector	Qdrant	Pinecone
Type	Postgres extension	Open-source vector database	Managed vector database
Hosting	Anywhere Postgres runs	Self-hosted or managed cloud	Managed only
Index types	HNSW, IVFFlat	HNSW with quantization options	Managed indexes
Filtering	SQL WHERE clauses	Payload filters during search	Metadata filters
Hybrid search	Combine with Postgres full-text search	Sparse and dense vectors	Sparse and dense support
Joins and transactions	Yes	No	No
Operations	Your Postgres team	You, or their cloud	None
On-prem or air-gapped	Yes	Yes	No

Questions that decide it

• Do you already run Postgres well? Then pgvector removes a whole system from your architecture.
• Do permissions and metadata filters matter on every query? Test filtered search performance on your data, because filtering is where systems differ most.
• Must data stay on-prem? That rules out managed-only services.
• Who will operate it at 3 a.m.? A managed service costs more and needs nobody on call for the database.

When to choose which

• Under a few million vectors, already on Postgres: pgvector.
• Heavy filtering, on-prem requirement, larger scale: Qdrant.
• No operations capacity, need to move fast: Pinecone.
• Prototype on a laptop: Chroma is also fine.

These ranges are rough, so load a realistic sample, measure recall and latency with your filters, and decide from that.

From the floor

In the financial RAG session, we used ChromaDB, an open-source vector database, to get the pipeline working locally first.

In the Neural Vault build, the application had to work in a completely air-gapped environment, with the internet switched off, which rules out a managed vector service and is the same constraint many regulated clients have.

Related

• Vector databases
• Vector index internals
• Metadata filtering and access control
• Nearest neighbour search

Sources

• pgvector
• Qdrant documentation
• Pinecone documentation