Technology

Choosing a vector database.

Almost every option retrieves well enough. The decision is usually made by operational fit, filtering behaviour and whether you want another system to run — not by benchmark recall.

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

	pgvector	Qdrant	Pinecone	Milvus
Operational burden	None if you run Postgres	One more service	Managed	High — distributed
Transactional with your data	✓	—	—	—
Metadata filtering	Full SQL	Rich, fast	Good	Good
Comfortable scale	Low millions; higher with tuning	10M+	100M+	1B+
Self-hostable	✓	✓	—	✓
Hybrid search built in	Via tsvector	✓	✓	✓
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

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.

WHAT ACTUALLY DECIDES IT

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.

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.

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.

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 — 4

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.

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.

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.

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.

Keep reading

Architecture

Enterprise RAG Systems

30-minute technical call · no deck