
Qdrant is still the safe default for new RAG projects in 2026, but the field moved on cost: Milvus 2.6 shipped 1-bit quantization, Pinecone launched Nexus to public preview, and object-storage-first newcomers Turbopuffer and LanceDB undercut the incumbents. An honest buyer's guide.
A deep read: the full picture, with the receipts.
The short answer#
For most new RAG projects in 2026, Qdrant is still the safe default: a fast Rust core, the most active release cadence in the field, and a pricing model with a free tier so you can start for nothing and scale up from there. If you already live inside PostgreSQL, pgvector with pgvectorscale is the answer before you shop for anything else. If you're counting vectors in the billions and cost-per-query is the real constraint, Milvus 2.6 and the new object-storage-first crowd (Turbopuffer, LanceDB, AWS S3 Vectors) are where the 2026 action moved.
One honest caveat up front: most of the public latency numbers in this space come from vendor or third-party benchmarks, not independent testing on your workload. Treat them as directional, not gospel, and benchmark on your own corpus before you commit anything to production.
Who should pick what, fast:
- Best overall / new RAG projects → Qdrant
- Best for existing Postgres shops → pgvector + pgvectorscale
- Best managed / zero-ops → Pinecone
- Best for billion-scale enterprise → Milvus
- Best for cost at scale (object-storage-first) → Turbopuffer
- Best open-source multimodal lakehouse → LanceDB
- Best for managed multimodal + hybrid search → Weaviate
- Best for fast prototyping → Chroma
- Already on AWS / MongoDB / Redis → S3 Vectors + Bedrock / Atlas Vector Search / Redis

Qdrant: Best overall#
Qdrant is a purpose-built vector database written in Rust, and it remains the strongest default for a new RAG project in 2026. In the Salt Technologies 2026 vector-database benchmark: a standardized test at 1M vectors / 1536 dimensions (median of 3 runs), published by a third party rather than something we ran independently, Qdrant posts the sharpest latency numbers in the group: roughly 4ms p50 / 25ms p99 in a managed cloud configuration at 1M vectors. Take the exact figures with a grain of salt given the methodology, but the direction, Qdrant is fast, matches most teams' hands-on experience.
Worth clearing up a common piece of misinformation: there is no "Qdrant 2.0." Qdrant is on the 1.x line, its 2026 releases run through the 1.17.x range, and its hybrid-search story is already mature rather than new-for-2026. The unified Query API (dense + sparse + ColBERT late-interaction, with BM25 / SPLADE++ / miniCOIL) landed in v1.10, and the Discovery API back in v1.7. If you read a 2026 post touting those as fresh features, it's recycled.
What's actually new in 2026 is memory cost and multitenancy:
- v1.15: more aggressive low-bit quantization for higher memory compression, plus better full-text filtering.
- v1.16: tiered multitenancy with tenant promotion, disk-efficient inline vector storage, and ACORN filtered search.
- v1.17: removes RocksDB entirely in favor of Qdrant's own gridstore engine.
The through-line is squeezing memory, and therefore your bill, without gutting recall.
Qdrant Cloud is resource-based: you pay for the RAM/CPU/disk you provision via a calculator, there's a permanent free tier (a small ~1GB cluster), and standard clusters land roughly in the $30–200/month range as of mid-2026. There is no flat "from $0.014/hour" rate: if you see that number quoted, it isn't from Qdrant.
Who it's for: Teams starting a new RAG project in 2026 who want low latency, a fast-moving open-source core, and the option to self-host or go managed without rewriting anything.
When to pick something else: If your team has zero DevOps capacity and wants a fully managed, set-it-and-forget-it service, Pinecone's operational edge is real.
Pinecone: Best managed / zero-ops experience#
Pinecone is the most polished managed vector database on the market. In the same benchmark it lands around ~8ms p50 and ~45ms p99 at 1M vectors: competitive, but behind Qdrant's ~4ms cloud figure at that scale. What Pinecone actually sells is the managed experience: automated backup/restore, sparse-dense hybrid search, integrated inference, and multi-region coverage.
The big 2026 story is Pinecone Nexus, and it has shipped further than most coverage suggests. It moved from early access to public preview in mid-2026, so as of this writing it's a real product you can try, not merely "announced." Nexus is a "knowledge engine" pitched to replace hand-built RAG pipelines, and it has two moving parts: a Context Compiler that produces versioned "Artifacts," and a Composable Retriever. You drive it with KnowQL, a declarative agent query language built on six primitives: intent, filter, provenance, output shape, confidence, and budget.
Pinecone's own claimed impact is "up to 90% less token spend," >90% task completion, and ~30x faster time-to-completion. Those are vendor figures, not third-party benchmarks: striking, but verify them in your own pipeline before you architect around them. The public preview also shipped a $20/month Builder tier, new Germany and Singapore regions, a native full-text search preview, and a partner marketplace.
Pricing (as of mid-2026): Builder from $20/month, Standard from ~$50/month, Enterprise from ~$500/month.
Who it's for: Teams that want to ship and not manage infrastructure. Startups with runway to spend. Anyone seriously evaluating the Nexus / KnowQL agent-first architecture.
When to pick something else: If you're cost-sensitive at scale, or you want to own your data plane and avoid proprietary query abstractions.

Weaviate: Best for multimodal and hybrid search#
Weaviate is one of the few databases here that treats multimodal ingestion (text, images, audio) as a first-class concern rather than a bolt-on. It scales comfortably into the tens of millions of vectors with low-double-digit-millisecond response times in published benchmarks, and its native BM25 + vector fusion gives you genuinely good hybrid search out of the box. GraphQL-based filtering is expressive and battle-tested.
Weaviate's 2026 agent story is Weaviate Agents, not an "Agent Skills for coding" product (a claim that floats around secondhand but doesn't map to anything Weaviate ships). The lineup is a Query Agent (natural-language retrieval), a Transformation Agent (enrich and transform data on ingest), and a Personalization Agent.
Weaviate Cloud now publishes three rungs: Engram, an always-free managed tier at $0/month with no credit card, Flex from $45/month pay-as-you-go with no commitment, and Premium from $400/month on a prepaid contract. So there's a real way to kick the tires, but the first paid rung is still a jump from Chroma or pgvector.
Who it's for: Teams building RAG pipelines that mix content types (documents + images + audio), or anyone who needs strong keyword + vector hybrid search without building their own fusion layer.
When to pick something else: Pure-text, latency-first workloads. Qdrant or Pinecone will serve you better and cost less. For open-source multimodal, LanceDB is the more natural rival (below).
Milvus: Best for billion-scale enterprise RAG#
Milvus is what you reach for when "billion" shows up in your vector-count requirements (supply-chain optimization, legal research, large-scale semantic search), and it integrates natively with LangGraph and LlamaIndex. In the Salt benchmark it posts around ~6ms p50 at 1M vectors, behind Qdrant and Pinecone at that scale, because the architecture optimizes throughput at scale over latency on small collections.
The 2026 release is Milvus 2.6 (GA on Zilliz Cloud, mid-2026), and the headline is no longer just scale: it's cost. (For the record, there is no "Milvus 3.0-beta with zero-copy data lake queries"; that release doesn't exist.) The real 2.6 story:
- RaBitQ 1-bit quantization: roughly 1/32 the index size versus float32, with a large memory reduction and, by Milvus's own numbers, several-fold higher QPS at around ~95% recall. Treat the QPS and recall figures as vendor claims.
- Native BM25 full-text search: Milvus claims it's several times faster than Elasticsearch, giving it credible native hybrid search.
- Built-in embedding functions: call OpenAI / Voyage / Cohere from inside the database instead of wiring an embedding step upstream.
- JSON path indexing: index into JSON fields for richer metadata filtering.
So the old knock, that Milvus is billion-scale-only with weak hybrid search, is out of date. 2.6 does native hybrid search and is explicitly repositioned around cost per vector.
Who it's for: Enterprise teams with genuinely large collections, existing data-engineering teams comfortable with distributed systems, and workloads where cost-per-query at scale matters more than time-to-first-query.
When to pick something else: If your collection is under ~10 million vectors and you don't have distributed-systems experience, Milvus is more machine than you need. And if your billions are mostly cold, an object-storage-first option (Turbopuffer, LanceDB, S3 Vectors) may be dramatically cheaper.
pgvector + pgvectorscale: Best for existing Postgres shops#
If your application already runs on PostgreSQL, the correct first answer to "how do I add vector search?" is pgvector with the pgvectorscale extension. You get ACID compliance, SQL-based filtering, and the whole Postgres ecosystem (backups, roles, extensions, ORMs) for free. At tens of millions of vectors with high recall, pgvectorscale delivers on the order of a few hundred QPS in published benchmarks. Lower than a dedicated vector DB, but for a large share of RAG use cases it's more than enough.
Two 2026 updates matter. pgvector 0.8.x added iterative index scans, which fix the long-standing overfiltering problem (where a restrictive WHERE clause could starve an HNSW/IVF scan of enough candidates to return), plus faster HNSW builds. Recent 0.8.x point releases have also shipped security and stability fixes, so pin to a current 0.8.x rather than an older build: get current. On top of that, pgvectorscale (Timescale) layers StreamingDiskANN with SBQ compression for indexes larger than RAM.
Who it's for: Teams already on Postgres who don't want to operate a second database. Applications where transactional consistency between vector and relational data is a hard requirement. Budget-conscious teams.
When to pick something else: If you're starting fresh with no Postgres dependency, or your collection will exceed ~100 million vectors under heavy concurrent load.
Chroma: Best for fast prototyping#
Chroma is the fastest path from zero to a working RAG prototype. It runs in-process for local development and has a simple, Python-first API. And the managed side grew up: Chroma Cloud is now generally available (GA since 2025), no longer alpha. Pricing leans on object storage and is billed by usage: $0.33 per GiB per month stored, $2.50 per GiB written, $0.0075 per TiB queried and $0.09 per GiB returned, on a Starter plan at $0/month with $5 in credits, and a usage-based Team plan as of mid-2026. The old "$2.50/GiB write, $0.33/GiB/mo storage" schedule is gone.
Who it's for: Developers building a proof of concept, hackathon teams, anyone who needs to validate a RAG idea in a weekend without standing up infrastructure.
When to pick something else: When your prototype becomes a production service with real users and hard SLA requirements, and you need enterprise access control that Chroma doesn't yet match.
Turbopuffer: Best for cost at scale (object-storage-first)#
Turbopuffer is one of 2026's biggest cost-efficiency stories. It's a managed vector database built object-storage-first: vectors live on S3-class storage with a caching layer, on top of the SPFresh index, so you're not paying to keep everything resident in RAM. The vendor pitch is up to ~95% cheaper than RAM-first systems for large corpora, with HIPAA and SOC 2 available on standard plans. It's been widely adopted by AI coding and search products this year.
Who it's for: Teams with large or slowly-accessed corpora where storage cost dominates the bill, and who are fine with a managed dependency.
LanceDB: Best open-source multimodal lakehouse#
LanceDB is an open-source, embedded/serverless vector database built on the Lance columnar format: closer to a "multimodal AI lakehouse" than a pure vector index. It stores vectors alongside the raw data (text, images, video) in one columnar store, supports DuckDB SQL retrieval, and scales to billions of rows. Like Turbopuffer, it leans on object storage; the project claims large cost savings versus in-memory systems. It's the more natural open-source multimodal rival to Weaviate.
Who it's for: Teams that want an open, file-format-native store for multimodal data, with SQL retrieval and no per-object managed pricing.
The rest of the field (use what you already run)#
Sometimes the best vector database is the one you're already operating.
- AWS S3 Vectors: a cold tier for billions of vectors that AWS moved toward general availability around late 2025, pitched as roughly ~90% cheaper with warm latency on the order of ~100ms. And Amazon Bedrock Knowledge Bases now wires up Aurora pgvector, OpenSearch, Neptune Analytics, S3 Vectors, Pinecone, MongoDB Atlas, and Redis: the default AWS-native RAG path if you're already on AWS.
- MongoDB Atlas Vector Search: the "use the database you already have" pick for MongoDB shops, exactly the pgvector argument, one document store over.
- Redis (Redis 8 vector sets / Amazon MemoryDB): sub-millisecond in-memory vector search, the right tool for latency-sensitive or agentic loops where every millisecond in the retrieval step compounds.
- Elasticsearch / OpenSearch and Vespa: mainstream production hybrid-search engines heavily used for RAG. If you already run one for keyword search, adding vectors there can beat standing up a new system.
Comparison table#
Latency figures come from the Salt Technologies 2026 benchmark (1M vectors / 1536 dimensions, median of 3 runs) and should be read as directional, not authoritative: benchmark on your own corpus before you decide.
How to choose#
1. Start with your existing stack. On Postgres? Try pgvector first. On MongoDB? Atlas Vector Search. On AWS? S3 Vectors + Bedrock Knowledge Bases. On Redis? Redis vector sets. The cost of operating zero new databases is real: only add a dedicated vector DB when you hit a wall.
2. Know your scale before you commit. Under 10 million vectors: Qdrant, Pinecone, Weaviate, or Chroma all work. 10–100 million: Qdrant, Weaviate, pgvectorscale, or Milvus. Billions where cost dominates: Milvus 2.6 (RaBitQ) or the object-storage-first tier, Turbopuffer, LanceDB, S3 Vectors. Scale mismatches: overbuilding with Milvus for a 500K-vector collection, or stretching Chroma into heavy production, are the most common expensive mistakes.
3. Pick your cost model consciously. The 2026 dividing line is RAM-first (Qdrant, Pinecone, Weaviate, classic Milvus: fast, more expensive at scale) vs. object-storage-first (Turbopuffer, LanceDB, S3 Vectors, Chroma Cloud: much cheaper on large or cold corpora, at the cost of higher tail latency). Match the model to whether latency or bill is your binding constraint.
4. Latency vs. throughput vs. ops burden: pick two. Qdrant gives you latency + ops simplicity. Milvus gives you throughput + scale. Pinecone gives you ops simplicity + reliability. Nothing wins all three without trade-offs. Be honest about which two matter most.
5. Hybrid search is not optional for most RAG. Pure vector search has a well-known recall problem on out-of-distribution queries and keyword-heavy lookups. Weaviate, Pinecone, Milvus 2.6, and Elasticsearch/OpenSearch make hybrid easy; Qdrant's Query API and sparse vectors handle it well; pgvector makes you build it. If you're not planning for BM25 + vector from day one, you'll retrofit it later.
The call#
Qdrant is still the best default vector database for RAG in 2026. It's among the fastest in the field, its release cadence is the most active (v1.15 through v1.17 this year, all aimed at cutting memory cost and adding multitenancy), and the free tier plus resource-based pricing means you don't overpay at small scale. The caveat: if your team has no ops capacity at all, Pinecone's managed experience is genuinely superior. You're trading some performance and long-term cost efficiency for infrastructure you never have to think about.
The bigger 2026 shift is underneath the rankings: cost. Milvus 2.6 chased it with 1-bit quantization, Pinecone shipped Nexus to public preview to cut token spend, and object-storage-first newcomers Turbopuffer and LanceDB undercut the RAM-first incumbents by a wide margin on large corpora. Pick for your binding constraint (latency, ops burden, or bill) and benchmark on your own data before you sign anything.
Our picks#
🏆 Top pick: Qdrant (best overall). Among the fastest numbers in the field, the most active 2026 release cadence, and a free tier plus resource-based pricing that doesn't punish you at small scale: the default pick for new RAG projects.
Frequently asked questions
Is Chroma good enough for production RAG?
More than it used to be: Chroma Cloud went generally available in 2025 with object-storage-based pricing, so the old "it's basically a beta" objection is retired. For low-to-moderate traffic and internal tools it's a legitimate production option now. The remaining gaps versus Pinecone, Qdrant, or Weaviate are enterprise features: fine-grained access control, advanced filtering, and harder SLAs. Plan for those before you scale.
Should I care about Pinecone Nexus / KnowQL?
Yes: it's shipped further than the headlines suggest. Nexus moved to public preview in mid-2026, with a Context Compiler (versioned "Artifacts"), a Composable Retriever, and the KnowQL agent query language (six primitives: intent, filter, provenance, output shape, confidence, budget). Pinecone claims up to 90% less token spend and 30x faster time-to-completion: vendor figures, not independent benchmarks, so evaluate it on your own pipeline before restructuring your architecture around it.
What's the cheapest option at billion scale?
Object-storage-first. Turbopuffer, LanceDB, and AWS S3 Vectors trade some tail latency for substantially lower storage cost by keeping vectors on S3-class storage instead of RAM. Milvus 2.6's RaBitQ 1-bit quantization attacks the same problem from the RAM-first side by shrinking the index. If your corpus is large and mostly cold, start there rather than with a fully in-memory system.
Can I switch vector databases later without rewriting my RAG pipeline?
Easier than switching a relational database, harder than it sounds. Most frameworks (LangChain, LlamaIndex, LangGraph) abstract the vector-store interface, so a swap is often a config change at the framework level, but you'll still need to re-embed and re-index your entire corpus, which has real time and compute cost at scale. Design for portability early. ---
Sources
- Pinecone pricingpinecone.io
- Pinecone 2026 release notesdocs.pinecone.io
- Weaviate Cloud pricingweaviate.io
- Qdrant Cloud pricingqdrant.tech
- Chroma Cloud pricingtrychroma.com
- turbopuffer pricingturbopuffer.com
- LanceDBlancedb.com
- LanceDB on GitHubgithub.com
- Milvus on GitHubgithub.com
- pgvector, Postgres vector extensiongithub.com
- pgvectorscale by Timescalegithub.com



Discussion