Best vector databases for RAG in 2026
Teams argue about this choice for weeks. It is one of the smaller decisions in a retrieval system, and here is the evidence for that.
The short answer
Postgres with pgvector is the right default for most RAG systems, because the store you already back up and monitor costs nothing new to operate. Switch when your filtering gets complex or your vector count outgrows one machine.
Retrieval quality is set by how you chunk documents and whether you rerank. The store decides what you operate, not what the answer says.
We have shipped retrieval on Supabase Postgres for Trading CoPilot and Lexpair, and on a separate service where the search behaviour needed it. Both were fine. Neither choice was the reason the project worked.
How this ranking was made
Verified
We ranked five stores on what a team carries after launch, not on benchmark charts. Benchmarks measure a tuned index on someone else's data. Your recall depends on your chunks and your embedding model, so a leaderboard position rarely survives contact with a real corpus.
Capabilities were read from vendor documentation on 11 August 2026 and are linked in each entry. We run retrieval on several of these in production, and that experience sets the criteria below.
Pure keyword search engines were excluded. They store vectors, but their ranking and filtering models differ enough that comparing them here would mislead.
- Operating burden
- What your team has to back up, patch and monitor that they did not already.
- Filtering behaviour
- What happens to results when you filter by tenant, date or permission. This breaks more demos than raw speed.
- The point it stops fitting
- When the store becomes your constraint rather than the chunking.
- Exit cost
- How hard it is to move your vectors somewhere else in two years.
The five at a glance
Capabilities read from vendor documentation on 11 August 2026.
| Store | Runs as | Hybrid search | Best moment to pick it |
|---|---|---|---|
| Postgres + pgvector | An extension in your existing database | Yes, with Postgres full-text search | You already run Postgres |
| Qdrant | Self-hosted, cloud, or embedded | Yes, documented hybrid queries | Filtering is the hard part |
| Pinecone | Managed serverless only | Yes, via separate sparse indexes | Nobody can carry database work |
| Weaviate | Cloud, Docker, Kubernetes, embedded | Yes, semantic plus keyword | You want built-in vectorising |
| Supabase (pgvector) | Managed Postgres | Yes, same as Postgres | Auth and storage in one place |
The ranking
Order reflects how many teams each one is right for, not raw capability.
Vector search inside the database you run
Pick this first unless you can name why it fails you. Your vectors sit beside your users and your permissions. A filtered search becomes an ordinary SQL join, not two systems you keep in sync.
The documentation lists two index types. HNSW gives better query performance at the cost of slower builds and more memory. IVFFlat builds faster and uses less memory, with lower query performance. Indexed vectors go up to 2,000 dimensions, which covers the common embedding models.
The quiet win is the boring one. No second backup, no second set of credentials, no third-party outage that takes retrieval down while the rest of your app is healthy.
Best for
- Teams already running Postgres for application data
- Retrieval that must respect per-user or per-tenant permissions
- Products where one outage surface is one too many
Not for
- Corpora far past what a single database machine holds comfortably
- Teams with nobody willing to look at a query plan
- Runs as
- Postgres extension
- Index types
- HNSW and IVFFlat
- Indexed dimensions
- Up to 2,000
- 02
Qdrant ↗
Dedicated vector engine with strong filtering
Move here when filtering is what hurts. Qdrant documents hybrid queries, quantization, payload filtering and reranking as first-class features. That is a different posture from bolting filters onto a nearest-neighbour scan.
It deploys three ways: managed cloud, self-hosted, or an embedded engine that runs in-process with no background service. That last option matters more than it sounds. It lets you develop against the real engine instead of a stub.
The cost is a second system. Someone now owns its upgrades and its backups, and your permission logic lives in two places.
Best for
- Search filtered by many metadata fields at once
- Teams who want to self-host rather than depend on a vendor
Not for
- Small teams with no appetite for another service to operate
- Projects where the corpus would fit in Postgres without complaint
- Deployment
- Cloud, self-hosted, embedded
- Documented features
- Hybrid queries, quantization, payload filtering
Fully managed serverless vector store
Choose Pinecone when nobody on the team should be operating a database. It is serverless and managed, so there is no instance to size and no upgrade to schedule.
Namespaces partition records inside an index. The documentation names this as the way to isolate one customer's data from another. It beats the alternative: a filter somebody must remember to apply every time.
Read the limits before committing. Metadata is capped at 40KB per record. Sparse indexes carry their own documented ceilings on upserts and queries per second. And there is no self-hosted escape hatch, so your exit plan is a migration.
Best for
- Teams with no database operator and no plans to hire one
- Multi-tenant products that want isolation by namespace
Not for
- Anyone who needs to run the store on their own infrastructure
- Workloads where per-record metadata runs large
- Runs as
- Managed serverless
- Tenant isolation
- Namespaces within an index
- Metadata limit
- 40KB per record
Open-source store with built-in vectorising
Weaviate suits teams who want the embedding step handled for them. It stores objects alongside their vectors and supports search on both semantic similarity and keywords, so hybrid retrieval is native rather than assembled.
Four deployment paths are documented: managed cloud, Docker, Kubernetes, and an embedded mode for quick evaluation. The Kubernetes path is the one enterprise platform teams usually want, and it is a genuine one rather than a community afterthought.
Weaviate is the pick when you want the embedding pipeline handled rather than assembled. Judge it against the operational load of the two above it.
Best for
- Teams who would rather not manage an embedding pipeline themselves
- Platform groups standardising on Kubernetes
Not for
- Projects that just need vectors next to relational data
- Teams wanting the smallest possible number of moving parts
- Deployment
- Cloud, Docker, Kubernetes, embedded
- Search
- Semantic and keyword
- Vectorising
- Built in
Managed Postgres with auth attached
This is pgvector with the operations handed to someone else, and it is how several of our systems run. Supabase is built on Postgres and documents its components openly: PostgREST for the API, GoTrue for auth, plus Realtime, Storage and Edge Functions.
The reason it earns its own entry is row-level security. Retrieval that must respect per-user access gets to reuse the same policies the rest of the application already enforces. We rely on that in Trading CoPilot, where each trader sees only their own data.
Everything is open source and a self-hosted product exists, so the exit is a migration you can actually plan. That is not true of every managed option here.
Best for
- Products already using Supabase for auth and storage
- Retrieval that has to honour row-level permissions
Not for
- Teams committed to a different cloud's managed database
- Very large corpora that want a purpose-built engine
- Built on
- Postgres
- Access control
- Row-level security
- Our use
- Trading CoPilot, Lexpair, ExtraaJe
- ChunkSplit documents so one idea stays whole.
- EmbedModel choice sets the ceiling on recall.
- FilterPermissions and dates, before ranking.
- RerankThe step most teams skip.
- StoreThe box everyone argues about.
Four of these five change your answers more than the last one does.
When none of these is the answer
Some retrieval problems do not need a vector store at all. Say your documents are few and people search by name, date or status. A plain database query beats semantic search and costs nothing to run.
A filter that matches very little is the other trap. Narrow the corpus hard enough and a similarity search returns almost nothing useful, so the feature looks broken while the data is fine. Your engineers will know the fixes; the point is that no store choice avoids the problem.
- 01Under a few thousand documents, test keyword search first and see if anyone complains.
- 02If the question is always about one record, fetch the record. Do not retrieve.
- 03If answers are wrong, change the chunking before you change the database.
Retrieval over real document sets, running in production
Trading CoPilot
Real-time AI trading alerts and execution companion for forex traders.
Read the case study →
PremiumAudit.io
AI automation for smarter insurance premium audits.
Read the case study →
TrialTriage
AI clinical trial matching for oncology nurses and insurers.
Read the case study →
Greenlight
AI ESG and sustainability research platform.
Read the case study →
Lexpair
AI legal lead generation and case matching for law firms.
Read the case study →
Questions buyers ask
01Does the vector database change how accurate our answers are?
Barely. Accuracy comes from chunking, the embedding model and whether you rerank results. Every store here does nearest-neighbour search well enough that swapping one for another rarely moves answer quality. Fix retrieval before you shop.
02Is pgvector fast enough for a real product?
Yes, for the corpus sizes most products actually have. pgvector supports HNSW indexing, which its documentation describes as better on query performance than IVFFlat. The limit that bites first is usually the size of the machine, not the extension.
03Why is Pinecone not first when it is the easiest to start with?
Because easiest to start is not the same as best to live with. Pinecone is managed serverless with no self-hosting option, so leaving means a migration. Ranking it first would suit teams for one quarter and inconvenience them for years.
04We left out Milvus and Chroma. Why?
We rank stores we have run or can assess against a specific buying situation. Milvus targets a scale most of our clients do not reach, and Chroma is common in prototypes that get rebuilt before launch. Leaving them out is more honest than padding the list.
05How many vectors before we outgrow Postgres?
There is no single number, and anyone quoting one is guessing at your hardware. The signal to watch is your own: index build times you notice and queries that slow under filters. Move when those appear, not on a rumoured threshold.
Not sure which one fits your stack?
Tell us what you already run and what you are retrieving. We will name the store we would pick and say why, on a scoping call that costs nothing.
“They will treat your vision like their own and build it that way.”
Ron Klabunde · Founder, SmartREI
