AISuffer
Guide intermediate Engineers Entrepreneurs Product Managers

Best Vector Database for RAG in 2026

pgvector vs Pinecone, Qdrant, Weaviate, and Milvus for RAG in 2026, with a benchmark-backed decision table and honest cost and scale tradeoffs.

For most RAG apps in 2026 the best vector database is the one you already run: Postgres with pgvector. A tuned HNSW index matches or beats dedicated vector databases up to about 1M vectors (5 to 50ms queries) and stays workable to roughly 50M. Reach for a purpose-built engine only when you need fast filtered search at scale (Qdrant), built-in vectorization or GraphRAG (Weaviate), zero-ops managed serverless (Pinecone), or genuinely billions of vectors (Milvus). The honest summary: pgvector wins on cost and simplicity for the long tail of apps, managed engines win once scale, filtering, or ops pressure crosses a threshold.

What a vector database actually does in RAG (and when you don’t need a dedicated one)

A vector database stores embeddings and answers nearest-neighbor queries: given a query vector, return the most similar stored vectors fast. In a RAG pipeline that is the retrieval step, you embed the user question, pull the closest chunks, and feed them to the model as context. For the formal definition of the category, see the vector database glossary entry.

The thing nobody selling you a vector database will lead with: at small scale you do not need a dedicated one. Below roughly 100k to 1M vectors, an index inside Postgres is plenty. A separate service adds a network hop, a second system to operate, and another bill. The dedicated engines earn their keep at scale, under heavy metadata filtering, or when you want features Postgres does not ship.

The five contenders at a glance: Pinecone, Weaviate, pgvector, Qdrant, Milvus

EngineTypeLanguageSweet spot
pgvectorPostgres extensionCYou already run Postgres, up to ~50M vectors
PineconeManaged serverless onlyClosedZero ops, willing to pay for it
QdrantPurpose-built, self/cloudRustFast filtered search, frugal memory
WeaviatePurpose-built, self/cloudGoBuilt-in vectorization, GraphRAG
MilvusPurpose-built, self/cloudGo/C++Hundreds of millions to billions of vectors

pgvector: Postgres is already your vector database

pgvector turns Postgres into a vector store. With a properly tuned HNSW index it matches or beats dedicated vector databases at the 1M-vector scale, delivering 5 to 50ms query latency that is production-appropriate for most SaaS apps, and it handles up to roughly 50M vectors comfortably (CallSphere and Vecstore 2026 benchmarks).

The payoff is operational. Your vectors live next to your relational data, so retrieval and your normal WHERE filters run in one query, inside one transaction, backed up by one system. Teams migrating from Pinecone to pgvector at medium scale report 40 to 60% cost reductions, especially on managed Postgres like Neon or Supabase. pgvector ships in Neon, Supabase, AWS RDS, and Tiger Data managed Postgres, so you rarely have to install anything. pgvector 0.9 (early 2026) added IVFFlat improvements, sparse vector support, and speed boosts.

Honest cons: standard pgvector HNSW starts to slow noticeably above 5 to 10M vectors. Above ~10M the guidance is to add the pgvectorscale extension (Timescale, now Tiger Data) for its StreamingDiskANN index. And tuning HNSW is on you, the defaults are conservative.

This is the engine behind a private RAG build when you want everything on infrastructure you control.

Pinecone: managed serverless, zero ops, watch the bill

Pinecone is the zero-ops choice. There is nothing to host or tune, you write vectors and query them through an API. For a team with no platform engineer, that is real value.

The catch is the pricing model. Pinecone serverless (2026) bills on four components: Write Units ($0.0000004/WU), Read Units ($0.00000025/RU), storage (~$3.60/GB/month, or ~$0.33/GB/month on the Standard plan), plus capacity reservation fees that activate at sustained load. The Standard plan has a $50/month minimum. Storage for 1M uncompressed 1,536-dim float32 vectors is ~$22/month, dropping to ~$3.60 to $5.40/month with Pinecone’s native 4 to 6x compression. The surprise on the invoice is usually the capacity fees ($50 to $150/month at sustained agent load), not the storage line.

Pinecone also loses on heavy benchmarks. On a 50M-vector test (Cohere 768-dim embeddings), Postgres with pgvector plus pgvectorscale hit 28x lower p95 latency and 16x higher query throughput than Pinecone’s storage-optimized (s1) index at 99% recall, at 75% less cost when self-hosted on AWS EC2. You pay Pinecone for not running infrastructure, not for winning benchmarks. See our Pinecone service profile for the full breakdown.

Qdrant: the performance and filtering pick

Qdrant (Rust) is built for fast filtered search. Its ACORN approach folds metadata filtering into HNSW graph traversal, so queries stay fast even when a filter eliminates 99% of candidates, which is exactly where naive filter-then-search falls apart. Qdrant 1.18 added TurboQuant (~8x compression with minimal recall penalty). It is frugal enough to run millions of vectors on a 4GB instance and posts the lowest p50 latency (~4ms) among purpose-built databases.

Choose Qdrant when your retrieval leans on metadata filters (per-tenant, per-document, per-date) and you want predictable low latency without renting a large box. Qdrant Cloud has a permanent free tier (0.5 vCPU, 1GB, ~1M vectors) and standard tiers around $30 to $200/month.

Honest con: it is one more service to run, and it does not bundle relational data or embedding generation the way pgvector and Weaviate respectively do.

Weaviate: built-in vectorization and GraphRAG

Weaviate (Go) bundles vectorization. You can send raw text and let built-in modules call OpenAI, Cohere, or HuggingFace at ingest, so you skip wiring an embedding pipeline yourself. It also doubles as a lightweight knowledge graph, which makes it a natural fit for GraphRAG where retrieval walks relationships, not just nearest neighbors. Weaviate 1.38 hardened production features (batch rate limiter, async replication). Weaviate Cloud serverless starts around $25/month.

Honest con: it needs more memory and compute than the alternatives at very large scale, and the bundled-everything design means you are buying into Weaviate’s way of doing ingest.

Milvus: built for billions of vectors

Milvus (Go/C++) uses a fully disaggregated architecture that separates compute and storage, so you scale reads, writes, and indexing independently into the billions of vectors. Milvus 2.6 added element-level Struct search, nullable vector support, and compaction improvements for high-delete workloads. Managed Milvus is Zilliz Cloud, which charges $0.096/CU-hour compute plus $0.02/GB/month storage, around $80 to $150/month for 1M 1536-dim vectors, with a free tier of 5GB plus 100 CU-hours.

Honest con: choose Milvus only when you are genuinely at hundreds of millions of vectors, and accept the extra operational complexity that the disaggregated architecture brings. Below that scale it is more machinery than you need.

When to choose which (decision table)

Your situationPickWhy
Already on Postgres, under ~10M vectorspgvectorNo new system, one query joins vectors and relational data
10M to 50M+ vectors, still want Postgrespgvector + pgvectorscaleStreamingDiskANN keeps latency low past HNSW’s limit
No platform engineer, want zero ops, budget for itPineconeFully managed serverless, no tuning
Heavy metadata filtering, want low latency on a small boxQdrantACORN keeps filtered queries fast, frugal memory
Want embeddings generated for you, or GraphRAGWeaviateBuilt-in vectorization modules and a knowledge-graph layer
Genuinely hundreds of millions to billions of vectorsMilvusDisaggregated compute/storage scales each axis independently

Self-hosting pgvector in production: HNSW vs IVFFlat and pgvectorscale

pgvector ships two index types and the choice matters. HNSW query latency is ~2 to 6ms versus IVFFlat ~2 to 10ms on the same data. HNSW gives lower latency and higher recall but builds slower and used ~3 to 4x the memory of IVFFlat at 1M vectors in testing. IVFFlat is the pick for batch updates, smaller datasets, or memory-constrained instances.

IndexLatencyRecallBuild speedMemoryChoose when
HNSW~2-6msHigherSlower~3-4xRead-heavy production, latency and recall matter
IVFFlat~2-10msLowerFasterLowerBatch updates, smaller data, tight memory
pgvectorscale (StreamingDiskANN)Low at scaleHighModerateDisk-backedAbove ~10M vectors

Practical default: HNSW for most production RAG, switch to IVFFlat only if memory is tight or you rebuild the index in large batches, and add pgvectorscale once you cross ~10M vectors.

The honest take: pgvector wins for most, managed wins at scale

Start with pgvector if you run Postgres, which is most teams. It is cheaper, it is one less system, and at the scale most RAG apps actually operate (under a few million vectors) it is fast enough that a benchmark gap with the specialist engines does not change user experience. The 40 to 60% cost savings teams report after leaving Pinecone are real and recurring.

Switch when a specific pressure forces it: billions of vectors (Milvus), aggressive metadata filtering at low latency (Qdrant), no appetite to run infrastructure (Pinecone), or you want vectorization and graph features handed to you (Weaviate). Pick the database to fit the constraint you actually have, not the one a vendor’s benchmark assumes.

FAQ

Is pgvector good enough for production RAG? Yes for most apps. A tuned HNSW index delivers 5 to 50ms queries up to ~1M vectors and stays workable to ~50M, which covers the majority of production RAG workloads.

At what scale should I leave pgvector? Standard pgvector HNSW slows above 5 to 10M vectors. Add pgvectorscale (StreamingDiskANN) past ~10M, and consider a dedicated engine like Milvus once you reach hundreds of millions.

Why are Pinecone bills higher than expected? The capacity reservation fees, not storage, are usually the surprise. They activate at sustained load and run $50 to $150/month on top of the $50/month Standard minimum.

HNSW or IVFFlat in pgvector? HNSW for read-heavy production where latency and recall matter. IVFFlat when memory is tight, the dataset is small, or you rebuild in big batches.

Foundations: embeddings, RAG, and the vector database definition. If you want a system on infrastructure you control, see private RAG. Vendor profiles: Pinecone and Weaviate.