The answer, up top. There is no single best vector database for RAG — there's the one that fits how you want to operate it. These tools all do vector search well; they differ on operational shape, on hybrid-search quality, and on whether you already run Postgres. So the decision, first:

Everything below is the reasoning. But note the thing that actually moves RAG recall the most is not which store you pick — it's your chunking, embeddings, and reranker. Get those right before you agonize over this table.

Why "operational shape" is the real axis#

Pick these apart by a speed-and-recall bake-off and you'll conclude they're roughly interchangeable, because on a small corpus they are. The useful axis is what you have to operate:

  1. A Postgres extension — pgvector / pgvectorscale. Vectors live in the database you already run.
  2. A server you run — Qdrant, Weaviate, Milvus. A standalone service with its own ops.
  3. An embedded library — LanceDB, Chroma (local). Runs in-process; nothing to deploy.
  4. A fully-managed cloud — Pinecone, Turbopuffer, Zilliz Cloud, Qdrant Cloud, Chroma Cloud. You run nothing and pay for it.

Choose the shape that matches your team and your traffic, and the shortlist collapses to two or three. Everything after is tie-breaking on hybrid search, filtering, and scale.

The Postgres default: pgvector (and pgvectorscale)#

If your application data already lives in Postgres, the boring correct answer is pgvector. It adds a vector type plus HNSW and IVFFlat indexes, so your embeddings sit in the same database as your rows — you filter with ordinary WHERE, join across metadata and vectors in one query, and back it all up as one system. The 0.8 line added iterative index scans, which fixes the classic "filter throws away most of your HNSW candidates" over-filtering problem that used to bite RAG apps with heavy metadata filters.

The ceiling is memory: HNSW wants your index in RAM, so past a few million high-dimensional vectors it gets expensive. That's where pgvectorscale comes in — its StreamingDiskANN index keeps vectors on disk with statistical binary quantization and label-aware filtering, pushing Postgres cost-effectively to ~50–100M vectors without leaving Postgres. Timescale/Tiger's own benchmark claims pgvectorscale matches Pinecone's throughput at a fraction of the cost on tens of millions of vectors — a vendor number, so treat it as directional and test on your data.

Reach for it when you already run Postgres and value one system over best-in-class retrieval. The honest weakness: hybrid search is assembly-required — you wire Postgres full-text (tsvector) to the vector side and fuse the scores yourself.

The hybrid-quality picks: Qdrant and Weaviate#

When retrieval quality on mixed queries is the priority — questions that carry both exact terms (an error code, a part number) and semantic intent — you want first-class hybrid search, and that's where a dedicated engine earns its keep.

Qdrant (Rust; self-host or Cloud) has the strongest sparse-neural story: native BM25, SPLADE, miniCOIL, and ColBERT multi-vector reranking, combined in one Query API, with quantization to cut RAM. Its v1.19 line (August 2026) added 4-bit TurboQuant storage and per-query IDF. It's the pick for teams that want top hybrid relevance on a budget and don't mind running a service.

Weaviate ships BM25F fusion out of the box with ranked and relative-score modes, plus modular embedding and reranker integrations — the more "batteries-included" of the two if you want the platform to handle more of the pipeline. It's heavier on resources and leans on Kubernetes at scale.

Both routinely beat pure-vector search on domain corpora in vendor tests (low-double-digit recall lifts); the lift is real, the exact number is vendor-published. If you're still deciding whether hybrid is worth it at all, that's really a retrieval-strategy question upstream of the store.

The scale-and-managed tier: Milvus, Pinecone, Turbopuffer#

The no-server picks: LanceDB and Chroma#

If you want nothing to deploy, two embedded options: LanceDB runs in-process on the Lance columnar format (think "SQLite for vectors and multimodal data"), stores on object storage, and supports IVF/HNSW/PQ plus in-table BM25 hybrid — a strong fit for edge, desktop, or multimodal RAG. Chroma is the prototyping default: a dead-simple embedded API that gets you to a running RAG loop fastest, with Chroma Cloud (serverless, object-storage, full-text + regex + metadata) as the graduation path when you outgrow local. Neither is the pick for very-large production scale, but most projects don't start there.

The one-line decision#

Same as it ever was with storage: don't run a server until you have to, and don't add a system you don't need.

And keep the perspective: the store is one component. If your answers are wrong, the fix is almost always upstream — better chunking, the right embedding model, and a reranker on top — before you re-platform the database. Build the store behind a thin index() / search() interface so swapping it later is a migration, not a rewrite, then measure retrieval quality honestly and let the numbers, not the leaderboard, pick the winner. (If what you're actually building is agent memory rather than a document knowledge base, that's a different decision — the access pattern isn't the same.)

One caveat worth stating plainly: nearly every head-to-head speed and cost number in this space in 2026 is vendor-published. Independent, apples-to-apples benchmarks across these systems are scarce, so read any "N× faster / cheaper" claim — including the ones above — as directional and confirm it on your own workload before you commit.