Choosing a vector database (and when you don't need one)
Most teams reach for a dedicated vector store too early. How to tell whether Postgres will do, and what to weigh when it won't.
Vector search is a feature, not an architecture. The first question is not which vector database to buy — it is whether you need one at all.
Under a million vectors, Postgres is probably fine
With pgvector, a database you already run, back up and monitor handles a surprising amount. You keep transactional consistency between your documents and their embeddings, you keep one operational surface, and you avoid an entire class of sync bug. For most business RAG, this is the right answer for longer than people expect.
Do you need a dedicated vector store?
- Under ~1M vectors, simple filteringPostgres + pgvector
- Heavy metadata filtering at scaleDedicated store
- Tens of millions, tight latencyDedicated store
- Strict tenant isolation per indexDedicated store
- You just want it to feel seriousPostgres + pgvector
The real reasons to move
Scale is the obvious one, but it is rarely the first. More often it is filtered search at scale, high write throughput, or needing a hybrid of keyword and vector ranking that your current store does badly.
- Tens of millions of vectors with tight latency requirements
- Heavy metadata filtering combined with similarity — often the real bottleneck
- Frequent re-embedding as content changes constantly
- Multi-tenant isolation where one customer's index must not touch another's
Weigh the operational cost honestly
A managed vector service is another vendor, another bill, another failure mode and another thing to keep in sync with your source of truth. That is often worth it. It is worth it a lot less often than it is chosen.
Whatever you pick, own the embeddings
Store alongside the vector
- The source text it was made from
- The embedding model and its version
- Chunk metadata — source, section, date, access scope
- A stable id you can re-index against
Otherwise
- You cannot re-index when the model changes
- You cannot filter by permission at query time
- You cannot cite the source of an answer
- A migration means re-deriving everything from scratch
Whatever you pick, own the embeddings
Store the source text and its embedding version alongside the vector. When you change embedding models — and you will — you need to re-index, and you cannot re-index what you cannot reproduce.