Pinecone vs Qdrant vs Weaviate vs Milvus vs pgvector: 2026 Benchmarks, Pricing & How to Choose

Every Retrieval-Augmented Generation (RAG) project I've shipped eventually hits the same wall: the vector database that felt fine in a demo starts costing real money — or real milliseconds — once it holds a few million embeddings. I've run that gauntlet on production AI products like DocSumm AI Summarizer and ContentForge AI Studio, where the retrieval layer is the difference between an answer that lands and one that hallucinates. So this is not a feature-table copy job. It's a working engineer's read on the five vector stores most teams actually shortlist in 2026: Pinecone, Qdrant, Weaviate, Milvus, and pgvector.

I'll give you the benchmark numbers that matter, the pricing math at the scale where it bites, and a decision framework you can apply the same afternoon. No vendor cheerleading.

The quick verdict (for people who scroll first)

• Already on Postgres and under ~10M vectors? Use pgvector. One less system to operate, and with the pgvectorscale extension it is genuinely fast.
• Latency-critical agent or search product? Qdrant. Its Rust core gives the lowest tail latency among the open-source options.
• You want zero infrastructure and predictable scaling, budget secondary? Pinecone serverless.
• Hybrid search with rich schema and built-in modules? Weaviate.
• Billion-scale, heavy indexing, dedicated platform team? Milvus.

Comparison at a glance

What the 2026 benchmarks actually say

Headline benchmark numbers are easy to cherry-pick, so anchor on the dimension your workload cares about: throughput (QPS) or tail latency — they are not the same fight.

Throughput: pgvector + pgvectorscale surprises people

The result that changed how I size single-node deployments: on a 50M-vector dataset at 99% recall, Postgres with pgvector and the pgvectorscale extension hit roughly 471 QPS versus Qdrant's ~41 QPS — an 11.4x throughput gap on a single node. Relax recall to 90% and the gap narrows but holds: about 1,589 QPS for pgvector against 360 for Qdrant, roughly 4.4x. The lesson is not "pgvector always wins." It's that a well-tuned Postgres node with StreamingDiskANN indexing punches far above the reputation pgvector carried in 2023.

Latency: Qdrant owns the tail

Flip to per-query latency and Qdrant's Rust engine pulls ahead. In 2026 benchmarks Qdrant lands around a 4ms p50 and roughly 12ms p99 at 10M vectors, edging Weaviate (~16ms) and Milvus (~18ms) at the p99 mark. For an interactive agent that fans out three or four retrieval calls per turn, that tail latency compounds — three sequential 18ms calls feel different from three 12ms calls once you add LLM time on top.

Indexing: Milvus is the speed demon

Milvus consistently posts the fastest index-build times and holds precision well, which matters when you re-embed large corpora often. The tradeoff: at very high dimensions or very large vector counts its query-side RPS and latency aren't class-leading. If your pattern is "ingest huge batches nightly, serve moderate query volume," that's a Milvus-shaped problem.

Unique data point from my own ops: across the seven aggregator sites I run daily content imports on, the retrieval workloads are bursty and small — tens of thousands of documents, not millions. At that scale every one of these engines returns in single-digit milliseconds and the benchmark deltas are noise. I mention this because most teams over-index on billion-scale benchmarks for a corpus that will never exceed 2 million vectors. Right-size to your real ceiling, not the headline.

Pricing: where the real decision happens

Performance differences are interesting; the bill is what gets escalated to your manager. Here is the cost shape that I keep seeing confirmed in 2026 pricing data.

At ~10M vectors (mid-size production)

• pgvector on managed Postgres (e.g. RDS): ~$45/month — you are mostly paying for an instance you may already run.
• Qdrant Cloud: ~$65/month.
• Pinecone Serverless: ~$70/month.
• Weaviate Cloud: ~$135/month.

At ~100M vectors (the gap explodes)

This is where managed-usage pricing stings. Pinecone can climb past $700/month, while a self-hosted Milvus or pgvector deployment can stay under $100/month in raw infrastructure — at the cost of the operational overhead you take on. Independent cost write-ups in 2026 keep landing on the same warning: vendor pricing pages tend to understate real all-in cost by 2.5x–4x once you add replicas, egress, and the headroom you need to avoid throttling.

The Weaviate pricing reset you should know about

Weaviate restructured its cloud pricing in October 2025. The old $25/month Serverless tier was retired. The replacement ladder: Flex from $45/month (shared cloud, pay-as-you-go, 99.5% SLA), Pro from $280/month (annual commitment, 99.9% SLA), and Premium from $400/month (dedicated infrastructure, 99.95% SLA). If a tutorial still references the $25 Serverless plan, it predates this change — budget accordingly.

The free-tier reality

Qdrant's 1GB cluster is free forever, which is enough to run a real prototype and even a small production workload. pgvector is free in the truest sense — it is just an extension on Postgres you likely already pay for. Pinecone and Weaviate free tiers exist but are time- or capacity-boxed enough that you'll graduate off them quickly.

Engine-by-engine: how I'd actually choose

pgvector — the default I reach for first

When I integrated semantic search into a Laravel/Postgres stack for an internal tool, the honest question was: do I need a second database at all? For anything under roughly 10M vectors, the answer is usually no. Keeping vectors next to your relational data means transactional consistency, one backup story, one access-control model, and SQL joins between metadata and embeddings without an extra network hop. With pgvectorscale and the StreamingDiskANN index, the old "pgvector is slow at scale" objection is mostly retired. The ceiling is real, though — past tens of millions of vectors with high write churn, a dedicated engine earns its keep.

Pick it when: you already run Postgres, your corpus is small-to-mid, and you value operational simplicity over squeezing the last millisecond.

Qdrant — my choice for latency-sensitive products

Qdrant is the one I recommend when a human is waiting on the result. The Rust implementation gives it the tightest tail latency of the open-source group, payload filtering is fast and expressive, and self-hosting on a $50–100/month box replaces a $200–400/month managed cluster if you can run it. The developer experience is clean and the API is pleasant. For an AI agent that does multiple retrievals per turn, that low p99 is not a vanity metric — it's user-perceived speed.

Pick it when: latency is the constraint, you want open source with a strong managed option, and you're comfortable with a resource-based pricing model.

Weaviate — batteries-included hybrid search

Weaviate's strength is breadth: native hybrid (keyword + vector) search, a flexible schema, and modules that bolt on embedding and reranking pipelines. If you want the database to own more of the RAG plumbing rather than wiring it yourself, Weaviate is compelling. The post-October-2025 pricing makes it the pricier managed option at the entry point, so the value has to come from those built-in capabilities.

Pick it when: hybrid search and a rich object schema matter, and you'd rather configure than assemble.

Milvus — built for the billion-scale tier

Milvus is the heavyweight. Its distributed architecture, fast indexing, and support for multiple index types make it the answer when you genuinely operate at hundreds of millions to billions of vectors. That power comes with operational weight — Milvus expects a platform team, or you pay Zilliz Cloud to carry it. For most products this is over-provisioning; for a few it's the only thing that holds.

Pick it when: you're at true large scale with frequent re-indexing and have the team (or Zilliz budget) to run it.

Pinecone — pay to never think about infrastructure

Pinecone's pitch is that you never see a server. Serverless autoscaling, a mature API, and strong reliability make it the lowest-friction path to production. You pay for that in usage-based billing that climbs steeply with scale, and in the fact that it's the only fully closed, no-self-host option here. For a team that wants to ship RAG this week and treat the vector layer as a solved utility, that tradeoff is often worth it.

Pick it when: engineering time costs more than infrastructure dollars, and you want managed-everything with no ops.

Index types: the setting that quietly decides your benchmark

Two engineers can benchmark the same database and report wildly different numbers because they picked different index types and parameters. It's worth understanding the three families you'll meet:

• HNSW (Hierarchical Navigable Small World) — the default in Qdrant, Weaviate, and pgvector. Excellent recall-to-latency balance, memory-hungry, and slower to build. The ef_construction and m parameters trade build time and memory for query accuracy. This is what most production RAG runs on.
• IVF (Inverted File) — common in Milvus and FAISS. Faster to build and lighter on memory, but you tune nprobe to balance speed against recall, and accuracy degrades faster if you under-tune it.
• DiskANN / StreamingDiskANN — the disk-backed approach pgvectorscale uses to push past memory limits. It's the reason pgvector's throughput numbers jumped so much; it keeps a graph on SSD instead of forcing everything into RAM.

The practical takeaway: when you read a benchmark, check the index type and recall target before you trust the QPS figure. A 471 QPS result at 99% recall and a 471 QPS result at 80% recall are not the same claim. Recall is the hidden axis that makes or breaks a fair comparison, and it's the first thing I pin down before believing any vendor's chart.

How I actually test before committing

Reading benchmarks is step zero. Before I commit a product to an engine, I run a small bake-off that takes about an afternoon, and it has saved me from at least two expensive mistakes:

1. Use your own embeddings, not the benchmark's. Public benchmarks usually run on SIFT or GIST vectors. Your OpenAI or Voyage embeddings have different dimensionality and distribution, and recall behavior shifts with them. Pull a representative 100K–500K slice of your real corpus.
2. Fix a recall target first, then measure speed. Decide you need, say, 95% recall@10, tune each engine to hit it, and only then compare latency and QPS. Comparing speed at different recall levels is the most common benchmarking error I see.
3. Measure with filters on. Almost every real query filters by metadata — tenant ID, date range, category. Filtered vector search performs very differently from unfiltered, and Qdrant's payload filtering versus pgvector's SQL WHERE clause behave differently under load. Test the query shape you'll actually run.
4. Watch p99, not just the average. Averages hide the slow tail that users feel. I log p50, p95, and p99 separately; an engine with a great average and an ugly p99 will generate support tickets.
5. Project the cost at your 18-month scale. Take the pricing model and multiply by your realistic future vector count and query volume, including replicas. The cheapest option at 1M vectors is often not the cheapest at 50M.

That five-step pass costs less than a day and tells you more than any third-party leaderboard, because it runs on your data, at your recall target, with your filters. I'd recommend it over trusting any single benchmark chart, including the ones in this article — treat published numbers as a shortlist filter, then verify on your workload.

A decision matrix you can apply today

The mistake I see teams make most

The recurring error isn't picking the "wrong" database — all five are good. It's choosing for a scale you don't have. I've watched teams stand up a distributed Milvus cluster for 300,000 documents because a billion-scale benchmark impressed them, then spend weeks babysitting infrastructure that a single pgvector index would have served from a node they already owned. My rule: estimate your realistic 18-month vector ceiling, then pick the simplest engine that clears it with headroom. You can migrate later — embeddings are portable, and re-ingesting a few million vectors is an afternoon, not a quarter. When I built the retrieval layer for DocSumm AI Summarizer, I deliberately started on pgvector against the existing Postgres instance rather than provisioning a separate engine. The corpus never crossed two million chunks, query latency stayed in single-digit milliseconds, and the "second database" I almost stood up would have been pure operational tax with no user-visible benefit. Starting simple cost nothing and saved a maintenance burden I'd still be carrying today.

Frequently asked questions

Is pgvector really production-ready in 2026?

Yes — with the pgvectorscale extension and proper index tuning, it serves millions of vectors with competitive throughput. The honest ceiling is around tens of millions of vectors and heavy concurrent write loads, beyond which a dedicated engine pulls ahead. For the majority of RAG apps, pgvector is not a compromise; it's the pragmatic default.

Which vector database is cheapest at scale?

Self-hosted open-source options (pgvector, Qdrant, Milvus) are cheapest in raw infrastructure — often under $100/month at 100M vectors versus $700+ for managed usage-based plans. But "cheapest" must include the engineer-hours to operate it. If your team's time is the scarce resource, a managed plan can be cheaper in total cost of ownership.

Do I need a dedicated vector database at all?

Often, no. If you already run Postgres and your corpus is under ~10M vectors, pgvector avoids an entire extra system. Add a dedicated engine when you outgrow that ceiling, need specialized indexing, or require latency a general-purpose database can't hit.

Qdrant vs Pinecone — which should a startup pick?

If you can run a container, Qdrant gives you open source, excellent latency, and a free tier to start, with lower cost at scale. If you'd rather never touch infrastructure and can absorb usage-based pricing, Pinecone is the faster path to production. It's an ops-appetite question more than a performance one.

Can I migrate between these databases later?

Yes, and you should design assuming you might. Your embeddings are just float arrays plus metadata — the lock-in is in the query API and index configuration, not the data. Keep your retrieval layer behind a thin interface and swapping engines becomes a contained task rather than a rewrite.

Bottom line

There is no single best vector database in 2026 — there's a best one for your scale, your latency budget, and your team's appetite for ops. Start with pgvector if you're on Postgres and small. Move to Qdrant when latency or scale demands a dedicated engine. Reach for Pinecone when you want zero infrastructure, Weaviate when you want built-in hybrid search, and Milvus when you're genuinely operating at billion-scale. Size to the workload you actually have, keep the retrieval layer swappable, and you'll spend your energy on the product instead of the plumbing.