pgvector vs Pinecone vs Qdrant: Vector DBs

The honest starting position

If you already run PostgreSQL and have fewer than a few million vectors, use pgvector and move on. It will not be the fastest option in a benchmark, and that will not matter — your retrieval quality will be determined by chunking, embedding choice and reranking, not by which index implementation served the nearest neighbours.

The benefit is substantial and unglamorous: no second datastore to operate, back up, secure and keep consistent. Your vectors sit in the same transaction as the rows they describe, so a document and its embedding cannot drift apart — a class of bug a separate store makes possible and that is genuinely annoying to debug.

Reach for a dedicated vector database when you have a specific reason. Below is what those reasons actually look like.

The comparison

Compare your options

Indicative positions as of 2026, moving quickly. Benchmark against your own corpus and query mix before committing — published benchmarks rarely resemble anyone's actual workload.
Criterion	pgvector	Qdrant	Pinecone	Milvus
Operational burden	None if you run Postgres	One more service	Managed	High — distributed
Transactional with your data	Yes	No	No	No
Metadata filtering	Full SQL	Rich, fast	Good	Good
Comfortable scale	Low millions; higher with tuning	10M+	100M+	1B+
Self-hostable	Yes	Yes	No	Yes
Hybrid search built in	Via tsvector	Yes	Yes	Yes
Cost at small scale	Effectively free	Low	Usage-priced	Infra cost
Best when	Postgres already exists	Self-hosted at scale	You want zero ops	Very large, dedicated team

What actually decides it

01

Filtering, not similarity

Real queries are almost never pure similarity — they are "similar, within this tenant, in these document types, not archived". How a store handles filtered search matters far more than raw recall, and pre-filter versus post-filter behaviour differs sharply between engines at high filter selectivity.

02

Update patterns

A corpus that updates continuously stresses index maintenance very differently from one rebuilt nightly. Some engines degrade noticeably under heavy incremental writes. Test with your write pattern, not just your read pattern.

03

Multi-tenancy

If you serve many customers, tenant isolation shapes the design — separate collections, a filtered field, or separate instances, each with different cost and blast-radius characteristics. Retrofitting isolation is painful, so decide early.

04

Who operates it at 3am

A managed service costs more per month and removes a category of incident. For a small team without dedicated infrastructure people, that trade is usually correct even when self-hosting looks cheaper on the invoice.

Questions

Questions about Choosing a Vector Database.

When does pgvector stop being enough?

Typically somewhere between one and five million vectors, though it depends heavily on filter complexity and query volume rather than count alone. The signal is usually latency under filtered queries rather than a hard wall. Because the ceiling is workload-specific, load-test with your real distribution before assuming you have outgrown it — many teams migrate earlier than they needed to.

Does the embedding model matter more than the database?

Considerably. Switching from a weak embedding model to a strong one, or adding a reranker, typically improves retrieval quality far more than changing vector stores. If retrieval quality is the problem, look at embeddings, chunking and reranking before you look at infrastructure.

Should we use hybrid search?

Almost always. Dense vectors handle semantic similarity; keyword search handles exact matches — product codes, error identifiers, proper nouns — which is precisely where embeddings are weakest. Combining them with reciprocal rank fusion is a small amount of work for what is usually a meaningful improvement on real corpora.

How do we migrate if we choose wrong?

Keep the source of truth in your primary database and treat the vector store as a derived index that can be rebuilt from it. Migration is then a re-embed and re-index rather than a data migration, which turns a scary decision into a reversible one. Designing for that from the start is worth the small extra effort.