The recommendation most vendors won't give you
If you already run PostgreSQL, start with pgvector. It handles the scale most business applications actually reach, adds no new infrastructure to operate, and keeps your vectors alongside the relational data you filter by. Move to something specialised when you have measured a reason.
Vector database selection attracts more discussion than it deserves for most projects. Here is a practical comparison and an honest view of when the choice actually matters.
The options compared
| pgvector | Qdrant | Weaviate | Pinecone | |
|---|---|---|---|---|
| Type | Postgres extension | Self-host or cloud | Self-host or cloud | Managed only |
| New infrastructure | None | Yes | Yes | None to run |
| Relational filtering | Native SQL | Payload filters | Payload filters | Metadata filters |
| Hybrid search | With Postgres FTS | Built in | Built in | Built in |
| Operational burden | Lowest if you have PG | Moderate | Moderate | Lowest overall |
| Scale ceiling | Millions | Very high | Very high | Very high |
| Cost shape | Your existing DB | Infrastructure | Infrastructure | Usage-based |
The factor people under-weight is filtering. Real queries are rarely pure similarity — they are "similar documents, for this customer, in this region, not archived". If that metadata lives in Postgres and your vectors live elsewhere, you either duplicate the metadata or make two round trips. pgvector avoids that entirely by keeping both in one query.
Choosing by situation
| Your situation | Sensible choice | Why |
|---|---|---|
| Already run Postgres, moderate corpus | pgvector | No new infrastructure; SQL filtering |
| Small team, want zero ops | Managed service | Operational simplicity is worth paying for |
| Very large corpus, high QPS | Dedicated vector DB | Purpose-built for that regime |
| Strict data residency | Self-hosted | Full control over location |
| Prototyping | pgvector or in-memory | Fastest to working; easy to change |
| Corpus under ~10k docs | Possibly no vector DB | Test whether hybrid keyword search suffices |
The last row is worth taking seriously. A well-tuned keyword search over ten thousand documents frequently outperforms a mediocre vector setup — and costs nothing to operate.
What actually determines retrieval quality
The database is rarely the constraint. In order of impact:
- Chunking strategy — determines what can be found at all.
- Embedding model choice — domain fit matters more than benchmark rank.
- Hybrid retrieval — combining keyword and semantic search.
- Reranking — precision within the candidate set.
- Metadata filtering — narrowing before ranking.
- The vector store itself — genuinely last, until you hit scale limits.
Teams routinely migrate vector databases hoping to fix retrieval quality, and are disappointed. If your recall is poor, the cause is almost always chunking or the absence of hybrid search. Both are fixable without changing infrastructure, and both should be exhausted first.
Operational realities to plan for
- Re-embedding cost. Changing embedding model means re-embedding the entire corpus. Budget for it, and avoid changing casually.
- Index build time. Large corpora take real time to index; plan for it in deployment.
- Incremental updates. How new and changed documents enter the index without a full rebuild.
- Deletion. Genuinely removing a document from the index — a GDPR requirement, and easy to overlook.
- Backup. Vectors are derived data, but re-deriving them is expensive. Back up or accept the rebuild cost.
That deletion point deserves attention for teams serving European customers. A deletion request must remove content from the index, not only from the source system, and some architectures make that harder than expected.
Keep your options open
- Abstract the retrieval interface. Your application should call your search method, not the vendor's SDK throughout.
- Store source documents separately from the index, so re-indexing never risks the originals.
- Record which embedding model produced each vector, so a migration is traceable.
- Keep an evaluation set so you can prove whether a change helped rather than assuming.
A practical recommendation
Start with pgvector if you have Postgres. Invest your effort in chunking, hybrid retrieval and reranking — that is where quality is decided. Revisit the infrastructure choice when you have a measured scale or latency problem, at which point you will know exactly what you need rather than guessing.
Choosing infrastructure for a RAG system? Tell us your corpus size and query patterns. See our AI agent service, RAG architecture, and general database selection.