When to use a vector DB — and when to use plain Postgres
The dedicated vector database is the most over-bought piece of infrastructure in 2026. Most teams already had the answer in their main database.
Every RAG project starts with the same purchase order: a dedicated vector database. Half the time it isn't necessary. A quarter of the time it actively gets in the way.
When pgvector (or equivalent) is enough
- Corpus size under 10–50M vectors, depending on dimension and query rate.
- Strong relational filtering needs (tenant ID, ACLs, time ranges).
- Hybrid retrieval where lexical scoring lives in the same place.
- Operational simplicity matters and you already run Postgres.
When a dedicated vector DB earns its keep
- Hundreds of millions to billions of vectors.
- High write rate with sub-second indexing requirements.
- Tight latency SLOs at high concurrency.
- GPU-accelerated indexes (HNSW on GPU, IVF-PQ at scale).
The actual decision criteria
Retrieval quality dominates retrieval substrate. A weaker embedding with strong filtering, hybrid retrieval, and re-ranking will out-perform a stronger embedding with a beautiful ANN index almost every time. Pick the substrate that lets you iterate on quality fastest. For most teams under 50M vectors, that's the database they already run.
The bill comes due either way. Spend it on the part of the system that moves quality.
Working on something like this?
Tell us about your stack. We'll come back with a scoped plan in two business days.