pgvector vs Pinecone vs Qdrant: choosing a vector database

The vector database comparison most teams run is the wrong one. They read benchmark tables, pick the fastest store, and then discover that the real problems were chunking, hybrid search and permissions, none of which the database solved. Our default is pgvector inside the Postgres you already run. We move to Qdrant, Weaviate or Pinecone when a specific, measurable requirement forces it: tens of millions of vectors, heavy metadata filtering at query time, strict per-tenant isolation, or an operations team that would rather pay for a managed service than tune an index.

This article sets out the decision as we make it on client work: what each store is good at, where it stops being good, what it costs to run, and a table you can use in a design review. It ends with how a build fits into the Retrieval & Knowledge Engineering service and what a realistic timeline looks like.

Why the vector database matters less than the retrieval design

A vector store does one thing: given a query vector, return the nearest stored vectors, optionally filtered by metadata. Everything that decides whether the answer is right happens around it. Parsing decides whether the text is intact. Chunking decides whether a passage is retrievable at all. Hybrid search decides whether a part number or a person's name can be matched exactly. Re-ranking decides which of the candidates actually answers the question. We covered those failures in why basic RAG fails in production, and none of them are fixed by switching databases.

So the sequence is: design retrieval first, build a golden set, measure recall, then choose the store that meets the measured need.

pgvector vs Pinecone vs Qdrant vs Weaviate, side by side

pgvector: the default until proven otherwise

pgvector adds a vector column type and approximate nearest-neighbour indexes (HNSW and IVFFlat) to Postgres. Its appeal is not performance; it is that vectors live next to the rows they describe. A chunk, its source document, its access-control list, its version and its embedding sit in one transaction. When a document is deleted, the vectors go with it. When a user's entitlements change, a join enforces it. Backups, replication, monitoring and the people who understand them already exist.

The limits are real. HNSW indexes consume memory that competes with the rest of your database. Filtered queries can be slow if the planner applies the filter after the nearest-neighbour search rather than before it. Past a few million vectors, or when p95 latency under filter matters, you will spend engineering time on tuning that a dedicated store gives you out of the box. The pgvector repository documents index parameters and these trade-offs plainly.

When pgvector is the right answer

• Corpus under a few million chunks and growing slowly
• Team already runs Postgres with backups and monitoring
• Permission-aware retrieval that joins on access-control tables
• Regulated data that must stay in an existing, audited database

Qdrant vs Weaviate: dedicated open-source stores

Both are purpose-built, open source and run anywhere you can run a container, which matters for clients with data-residency requirements or a private VPC. The differences are in emphasis rather than capability.

Qdrant is written in Rust and is strongest on filtered search: payload indexes let you combine dense vectors, sparse vectors and structured filters in one query without the planner surprises of a relational database. Its collection model maps cleanly onto per-tenant or per-source partitioning. The Qdrant documentation is precise about memory and quantisation options, which helps when sizing hardware for a self-hosted deployment.

Weaviate is more batteries-included: hybrid search with BM25 fusion is built in, native multi-tenancy isolates tenants at the shard level, and vectoriser modules can call embedding models for you. The Weaviate documentation covers the multi-tenancy design in detail.

We pick between them on team familiarity and the shape of filtering the golden set demands. Either is sound for a self-hosted, filter-heavy, multi-tenant workload; neither is worth adopting for a small corpus that Postgres would serve.

Pinecone: managed convenience with a residency cost

Pinecone is fully managed: no cluster to size, no index to rebuild, no on-call for a stateful service. For a product team without a platform function that is a genuine benefit. The Pinecone documentation is clear about the serverless and pod-based models and their filter limits.

The trade-offs are the ones every managed store carries: vectors and metadata leave your infrastructure, region choice is constrained, and the store cannot join on your own tables for permissions, so entitlements must be copied into metadata and kept in sync. For banking, healthcare or public-sector clients in India, residency is often decisive on its own; see self-hosted LLMs for BFSI.

The questions that actually decide it

How many vectors, and how fast is it growing?

Count chunks, not documents. A ten-thousand-page manual chunked by section may be fifty thousand vectors; a ticket archive may be millions. Under a few million and slow growth, pgvector. Tens of millions or fast growth, a dedicated store.

How complex are the filters?

If every query filters on tenant, document type, date range and access group, filtered performance dominates. Test it with real filters on a realistic sample before deciding; this is where pgvector can surprise you and Qdrant tends not to.

Who runs it, and where must the data live?

A self-hosted store is another service that can fill its disk or lose a node; if nobody owns that, managed Postgres with pgvector or a managed vector cloud is the honest answer, and the Care Plans cover the gap. If data must stay in your VPC or in India, managed-only stores are out unless the vendor offers that region and compliance accepts it.

A worked example

A mid-sized SaaS company came to us with an internal knowledge assistant that had been prototyped on a managed vector service. It worked in the demo. In review, three things were found. First, the corpus was under a million chunks and would not pass a few million for years. Second, the hardest queries were permission-filtered: a support engineer should see product docs and their own team's runbooks, not the finance wiki. Third, the company's data-processing terms with enterprise customers restricted where derived data could be stored.

We moved the store into the existing Postgres with pgvector, enforced entitlements with a join against the identity tables, added Postgres full-text search for hybrid retrieval and a re-ranker on top. Recall on the golden set improved, not because of the database but because hybrid search caught the exact-match queries the prototype had missed. Had the corpus been thirty million vectors with per-tenant collections, the same review would have pointed to Qdrant in the client's VPC. The in-app copilot case study shows the same retrieval design inside a product.

Team and timeline

Standing up the store is a small part of a retrieval build. A typical engagement is a retrieval-focused AI engineer and a data engineer for four to eight weeks: the first fortnight on the corpus audit, golden set and chunking; then retrieval tuning; then permissions, refresh and the answering layer. The database decision is made at the end of week two with measurements in hand.

If the question is only "which store, and will our retrieval work at all?", a three-week ProofRun at $6,250–10,500 answers it with a golden set and a working pipeline. A full build under the Retrieval & Knowledge Engineering service starts at $14,000 / ₹8.8L; current figures are on the pricing page. Clients own the code, the index and the eval set.

Before you start: a checklist

• Count chunks, not documents, and estimate growth over two years
• Write down the filters every query will carry: tenant, type, date, entitlement
• Collect 100–300 real questions with verified source passages
• Decide whether permissions are enforced by join or by metadata copy
• Confirm where the data may live and which regions are acceptable
• Name the person or plan that owns the store operationally
• Write retrieval against an interface so the store can be swapped
• Test filtered query latency on a realistic sample before committing

Glossary

• HNSW: a graph-based approximate nearest-neighbour index used by most vector stores; fast to query, memory-hungry to hold.
• IVFFlat: an index that clusters vectors and searches a subset of clusters; cheaper to build, usually less accurate than HNSW.
• Sparse vector: a keyword-style representation (such as BM25 weights) that complements dense embeddings in hybrid search.
• Payload: Qdrant's term for the metadata attached to each vector and used for filtering.
• Quantisation: compressing vectors to reduce memory at a small cost in accuracy.

Related reading

See why basic RAG fails in production for the six failures the database does not fix, hybrid search for the biggest relevance gain most systems can make, and what a RAG system costs for budgeting the whole pipeline.

Choose the retrieval design first, measure it, and let the numbers pick the store; most of the time they will pick the database you already have.