Choosing a vector database is one of the first infrastructure decisions on any retrieval or RAG project, and it is one of the easiest to overthink. The market is loud, every vendor benchmark shows them winning, and the differences that matter in production rarely show up in a landing page. Here is how we actually decide in 2026, stripped of the marketing.
First, do you even need a dedicated vector DB?
For most teams, the honest answer is not yet. If you are already running PostgreSQL, the pgvector extension lets you store and search embeddings right next to your application data with no new system to operate. Up to a few million vectors with reasonable latency requirements, this is the right answer far more often than the discourse suggests. One database, one backup story, one thing to monitor.
The best vector database is usually the one you are already running. Add a new system when the data forces you to, not before.
You graduate to a dedicated vector store when one of a few things becomes true: your vector count climbs past what your Postgres instance can index comfortably, your latency budget tightens, or you need features like sophisticated metadata filtering, hybrid search, or multi-tenancy that are painful to build yourself.
The contenders, and when each wins
pgvector
The default. Best when you already use Postgres and your scale is modest to mid-sized. You keep transactional guarantees, joins against your real data, and a single operational surface. The ceiling is real but higher than people expect, especially with the newer indexing options. Reach for something else when you feel that ceiling, not in anticipation of it.
Pinecone
The managed-service choice. Best when you want vectors to be somebody else problem: no servers, no index tuning, predictable scaling. You pay for that convenience, and you accept a separate system from your primary data, but for a team that wants to focus on the product rather than the infrastructure it is a defensible default at scale.
Weaviate
The feature-rich open-source option. Best when you want hybrid search, rich metadata filtering, and built-in module support without assembling it yourself, and you are willing to run and operate it (or pay for their cloud). More moving parts than pgvector, more control than Pinecone.
Turbopuffer
The cost-at-scale specialist. Best when you have a very large number of vectors and read patterns that suit object-storage-backed retrieval, where keeping everything in RAM would be ruinously expensive. It trades some latency for a dramatically lower cost curve at large scale, which is exactly the right trade for some workloads and the wrong one for latency-critical paths.
The gotchas at a million vectors and beyond
The benchmarks you see are almost always pure nearest-neighbour search on clean data. Production is messier, and the costs that bite are rarely the ones advertised.
- Metadata filtering changes everything. Filtering by tenant, date, or category alongside the vector search can dominate latency, and systems differ wildly in how well they handle it. Test with your real filters, not just raw similarity.
- Recall is a dial, not a constant. Approximate indexes trade accuracy for speed. The default settings may quietly drop relevant results, so measure recall on your own data rather than trusting the index.
- Re-indexing is an operational event. Updating embeddings at scale, after a model change, is slow and resource-hungry. Plan for it before you are forced to do it under pressure.
- Cost scales with dimensions and memory, not just row count. High-dimensional embeddings held in RAM get expensive fast, which is the whole reason the storage-backed options exist.
How we actually choose
We start by asking whether pgvector clears the bar, because the cheapest system to operate is the one you already run. If it does not, we map the workload, vector count, latency budget, filtering needs, update frequency, and budget, against the trade each system is built around, then we benchmark the two finalists on the client real data and real query patterns. The right answer is workload-specific, and anyone who names a winner before seeing your data is selling, not advising.
If you are weighing a vector store for a RAG or search system and want a recommendation backed by a benchmark on your own data rather than a vendor chart, that is exactly the kind of decision we help teams make.