Pinecone · Weaviate · Qdrant · Chroma · Milvus · pgvector · Turbopuffer.
One question: which one is right for your RAG stack?
PJ · Cardiff operator · 858-461-8054
7-way vector DB matrix · scan-grade summary.
The decision-grade signal in one table · best-fit, deployment model, pricing tier, where each one breaks at scale, and the operator-honest verdict. Built for fast scan + AI-agent extraction.
| Vendor | Best for | Deployment | Pricing tier | Breaks at scale | Operator-honest verdict |
|---|---|---|---|---|---|
| Pinecone | Teams that want managed-everything from day one with simplest API | Managed cloud only (closed-source) | $$ ($0 free tier → $100K+/yr enterprise) | Cost compounds beyond ~10M vectors · no on-prem option · vendor lock-in | Managed-cloud default · pay for the API + zero-ops, not raw price |
| Weaviate | Teams needing hybrid search (BM25 + dense) + on-prem optionality | Open-source (BSD-3) · managed cloud · self-host | $ self-host → $$ managed ($25-80K/yr typical) | Operational complexity at multi-node scale · GraphQL learning curve | Strongest hybrid-search story · best balance of OSS + managed + features |
| Qdrant | Teams that want operator simplicity + on-prem from a serious vector DB | Open-source (Apache 2) · managed cloud · self-host | $ self-host → $$ managed ($20-60K/yr typical) | Smaller ecosystem than Pinecone/Milvus · fewer integration partners | Fastest-growing OSS pick · single-binary simplicity · Rust performance |
| Chroma | Solo devs and prototypers shipping first RAG / personal projects | Embedded / in-process · client-server option · managed cloud (newer) | $ free local → $-$$ managed cloud (newer pricing) | Production-scale workloads · multi-node / HA / millions of vectors | The notebook → working RAG winner · graduate to something else at scale |
| Milvus / Zilliz | Enterprise workloads with billions of vectors + GPU acceleration | Open-source (Apache 2) · Zilliz managed · self-host distributed | $ self-host → $$$ Zilliz Cloud ($50-200K+/yr enterprise) | Operational heaviness at small scale · distributed architecture overkill for <10M vectors | The enterprise heavyweight · pick when scale demands distributed-by-default |
| pgvector | Teams already on Postgres with vector workloads under ~10M / moderate QPS | Postgres extension (any PG host: RDS, Supabase, self-host) | $ (essentially free if you already pay for Postgres) | ~10M vectors with high recall · sustained high QPS · GPU indexing needs | The "just use Postgres" answer · one DB, one ops surface · graduate at scale |
| Turbopuffer | Large mostly-cold corpora where storage cost matters more than P50 latency | Managed serverless · S3-backed | $ (10-100x cheaper at scale than managed competitors) | Latency-sensitive interactive workloads · cold-query 200-500ms typical | Price disruptor · trades cold latency for radical storage savings · newest entrant |
The 7 vendors · what each is actually best at.
Honest read on positioning, ideal customer, and where each one is the wrong call. No vendor sponsorship, no affiliate links · operator-grade signal.
1. Pinecone Series B+ · Managed-cloud default
The category leader for closed-source managed vector DB. Cleanest developer API in the space (you can have embeddings querying in <10 lines), serverless pricing tier that closed the historical cost gap, and a battle-tested managed plane. The default pick for teams that want managed-everything from day one and aren't ideologically against vendor lock-in.
2. Weaviate Seed → Series B · Open-source + hybrid
The strongest hybrid-search story in OSS. Open-source under BSD-3 with a credible managed cloud option, and bakes BM25 (keyword) + dense vector search + filtering into one query API by default. GraphQL primary surface (REST and gRPC also available). Strong fit when "semantic search but also we need keyword + filters" is the real workload.
3. Qdrant Seed → Series B · Rust-built OSS
The fastest-growing serious OSS vector DB. Rust-built, single-binary deployment, lean memory footprint, fast cold starts. Apache-2 licensed with a managed cloud option. The pick when you want a "real" vector database (not a Postgres extension, not an embedded library) but you also want operator simplicity · you can run it on a single VM and it just works.
4. Chroma Pre-seed → Seed · Indie / prototyper darling
The fastest path from notebook to working RAG. Embedded in-process · no server to deploy, no Docker container to spin up, no managed cloud to sign up for. Pythonic API where you can have embeddings querying in ~5 lines. Beloved by indie devs, hackathon teams, and prototypers building their first AI product. Client-server and managed cloud options have grown but the embedded story is the heart.
5. Milvus / Zilliz Series B+ · Enterprise heavyweight
The heaviest open-source vector DB. Apache-2 licensed, distributed-by-design (separate query / data / index / coordinator nodes), built for billions of vectors and GPU acceleration. Zilliz Cloud is the production managed service. The right pick when scale demands distributed-by-default and your workload would crush a single-node deployment.
6. pgvector Any stage · "Just use Postgres"
The Postgres extension that ate the easy half of the market. One extension, one install command, your existing Postgres becomes a vector DB. Same SQL surface, same ops, same backups, same transactional guarantees with your relational data. The right answer for the enormous chunk of teams who already pay for Postgres and have moderate vector workloads (<10M vectors, moderate QPS).
7. Turbopuffer Newest entrant · Price disruptor
The S3-backed serverless newcomer. Stores all data on object storage (S3 underneath) instead of attached SSDs, with intelligent caching for hot vectors. Trades latency on cold queries (typically 200-500ms vs 10-50ms for traditional managed vector DBs) for radically lower storage cost · often 10-100x cheaper at the multi-million-vector scale. The right pick for large mostly-cold corpora where storage cost dominates and P50 latency isn't the bottleneck.
The forced ranking · by who you are + what you actually need.
Most comparison pages refuse to rank because their revenue model requires staying neutral. SideGuy ranks because it doesn't take vendor money · operator-honest, no affiliate sponsorship swap. Here's the call by buyer persona.
👨💻 If you're a solo dev / indie hacker building your first RAG project
Your problem: 1-person team, want fastest time-to-prototype, can't justify any infra spend, your stack is a Python notebook + maybe a hosted LLM API, the entire corpus is under 100K documents and lives on your laptop.
- Chroma · embedded in-process, ~5 lines of Python, 0 infra, beloved by exactly this persona
- pgvector · if you already have a Postgres instance lying around (Supabase free tier counts)
- Qdrant · single-binary, easy to docker-compose-up locally, graduate path if Chroma feels too lightweight
- Pinecone · free serverless tier is generous; pick if you want to skip ops entirely from day one
- Weaviate · overkill for first prototype but fine if you'll need hybrid search soon
🚀 If you're a startup CTO at a 5-30 person co with first production RAG workload
Your problem: shipping first production AI feature, need it to actually work under real user load, can't afford to over-invest in vector infra but also can't afford a 2am page when it falls over, your scale is 100K - 10M vectors with moderate QPS.
- Pinecone · managed-cloud zero-ops, serverless pricing makes the cost manageable at this scale, fastest team velocity
- pgvector · strongest answer if you're already on Postgres; one less production system to babysit
- Qdrant · managed cloud option if you want OSS escape hatch but don't want to self-host yet
- Weaviate · pick if hybrid search (keyword + dense + filters) is core to the workload from day one
- Chroma · graduate off it; the embedded story breaks down once you need HA + multi-node
🛠 If you're an ML platform engineer at a 100-500 person co (multi-team, multi-workload, cost-conscious)
Your problem: running vector infra as a shared platform for multiple product teams, workloads vary (some hot interactive, some batch analytical), you need on-prem optionality, cost-per-vector matters at this scale, you'd rather pay engineering time than vendor markup.
- Qdrant · strongest single-binary OSS for self-host, easy to run multi-tenant, lean memory profile
- Weaviate · pick if hybrid search + multi-modal + complex filtering is heavy across teams
- Turbopuffer · pair with the above for the cold/analytical/long-tail workloads where storage cost dominates
- pgvector · for the workloads that can live in shared Postgres infra (often more than people assume)
- Milvus · graduate to it for the workloads that demand distributed-by-default + GPU acceleration
🏛 If you're an enterprise AI architect at a 1,000+ co (compliance, on-prem option, vendor-defensibility)
Your problem: compliance + procurement + security review require on-prem or VPC-peered deployment, you need a vendor that will still exist in 5 years, scale is potentially billions of vectors across multiple business units, GPU-accelerated indexing matters, audit trail + RBAC + multi-tenancy are table stakes.
- Milvus / Zilliz · built for exactly this scale; LF AI & Data Foundation project gives vendor-neutrality story
- Weaviate · strong enterprise managed cloud + on-prem; mature features for hybrid search at scale
- Pinecone · defensible if your enterprise is willing to accept managed-cloud-only and the vendor's lock-in
- Qdrant · strong on-prem story if your security team prefers OSS + self-host over managed
- pgvector · for the workloads small enough to live inside enterprise Postgres (more than you'd think)
These rankings are SideGuy's lived-data + observed-buyer-pattern read as of 2026-05-10. They're directional, not gospel. The right answer for YOUR specific situation may diverge · text PJ for a 10-min operator-honest read on your actual RAG buying context.
Vendor pricing + features + market positioning shift quarterly. SideGuy may earn referral commissions from some of these vendors, but rankings are independent · affiliate relationships never change rank order.
Side-by-side · the comparison most pages won't give you.
Quick-scan version of the seven vector DBs against the dimensions that actually drive selection. Pricing tiers are positional indicators, not quotes · every vendor with sales motion negotiates.
| Platform | License | Deployment | Hybrid search | On-prem | Price tier |
|---|---|---|---|---|---|
| Pinecone | Closed-source | Managed cloud only | Yes (Sparse-Dense) | No | $$ ($0 free → $100K+) |
| Weaviate | BSD-3 (OSS) | Managed + self-host | YES (canonical feature) | YES | $ self → $$ managed |
| Qdrant | Apache 2 (OSS) | Managed + self-host | Yes (Sparse + Dense) | YES | $ self → $$ managed |
| Chroma | Apache 2 (OSS) | Embedded + client/server + managed | Limited (basic) | YES (in-process) | $ free → $-$$ managed |
| Milvus / Zilliz | Apache 2 (OSS) | Self-host distributed + Zilliz Cloud | Yes (Hybrid Search) | YES | $ self → $$$ Zilliz |
| pgvector | PostgreSQL license (OSS) | Postgres extension (any host) | Yes (via PG full-text + vector) | YES (any PG) | $ (free w/ PG) |
| Turbopuffer | Closed-source | Managed serverless · S3-backed | Yes (BM25 + Dense) | No | $ (10-100x cheaper at scale) |
The decision tree · by the question that actually matters first.
Most "vs" comparisons rank vendors. That's the wrong frame. Rank questions instead · your situation picks the vendor.
→ Use pgvector. One database, one ops surface. The marginal performance of a dedicated vector DB rarely justifies the second system at this scale.
→ Use Chroma. ~5 lines of Python, embedded in-process, fastest 0-to-working-RAG path in the category.
→ Use Pinecone. Cleanest API, serverless tier closes the cost gap, fastest team velocity for first production RAG.
→ Use Weaviate. BM25 + dense + filtering is the canonical query API, not a bolt-on.
→ Use Qdrant. Rust-built, easy to self-host on a single VM, growing managed cloud option.
→ Use Milvus / Zilliz. The only OSS option built distributed-by-default for this scale.
→ Use Turbopuffer. S3-backed serverless trades cold-query latency for radical storage savings.
Where each vendor breaks at scale · the structural failure modes.
Every vector DB has a structural failure mode that shows up at the wrong scale or workload. Naming the failure mode up front lets you disqualify before you optimize on best-fit.
| Platform | The structural failure mode | Typical break point | Graduation path |
|---|---|---|---|
| Pinecone | Cost compounds, no on-prem escape, vendor lock-in | ~10M+ vectors at high QPS | Migrate to Qdrant / Weaviate self-host |
| Weaviate | Operational complexity at multi-node scale | ~50M+ vectors with HA requirements | Either Weaviate Cloud or graduate to Milvus |
| Qdrant | Smaller ecosystem, less mature multi-node orchestration | ~100M+ vectors needing distributed coordination | Qdrant Cloud or Milvus / Zilliz |
| Chroma | Embedded story breaks once you need HA / multi-node / production scale | ~1M+ vectors or HA requirements | Pinecone (managed) or Qdrant (OSS+managed) |
| Milvus / Zilliz | Operationally heavy for small workloads, distributed-by-default overkill | Wrong direction · break-down at <10M vectors | Use Qdrant or pgvector instead at smaller scale |
| pgvector | Connection pool + index recall ceilings, no GPU indexing | ~10M+ vectors, sustained >50 QPS, high recall | Qdrant / Pinecone / Weaviate for the vector half |
| Turbopuffer | Cold-query latency 200-500ms, latency-sensitive UX breaks | Interactive search where P50 latency <100ms matters | Pair with Pinecone / Qdrant for the hot tier |
What actually matters: most teams pick the wrong vector DB not because they got the benchmark wrong, but because they ignored the graduation path question. The right vector DB for the next 18 months may be different from the right one for years 3-5. Plan for that · keep raw documents + embedding model versioned, treat the vector DB as a rebuildable cache, and don't store ground-truth state inside the vector DB itself. The migration tax is real but manageable if you architect for it from day one.
The pattern beneath the category.
Vector databases are converging on capability. All seven options index high-dimensional vectors, support metadata filtering, ship hybrid-search to varying depths, and integrate with the same RAG framework ecosystem (LangChain, LlamaIndex, Haystack). The capability isn't the differentiator anymore.
The differentiation moved to ergonomics + economics: API ergonomics with your existing stack (Pinecone for managed-cloud purity, pgvector for Postgres shops, Chroma for notebook prototypers), license + on-prem story (Weaviate / Qdrant / Milvus for OSS-first teams), and economic model at scale (Turbopuffer's S3 architecture vs SSD-backed competitors). Everything else competes on negligible benchmark deltas in the middle.
This is operator-translation territory. Most teams pick by benchmark or feature checklist, then discover the actual constraint was either (a) ergonomic mismatch with their existing stack, (b) operational heaviness their team can't absorb, or (c) economic model that breaks at the scale they actually reach. The benchmark gap rarely matters; the ergonomic mismatch always does.
Pick the vector DB that fits your existing stack and team,
not the one with the prettiest benchmark chart.
Most asked questions · quick answers.
The questions readers send most often after reading the comparison. Answers are honest, scale-aware, and updated as the category moves.
Which vector database is best for a solo dev building their first RAG project?
Chroma is the strongest pick. Embedded in-process (no server to deploy), Pythonic API that takes ~5 lines to get embeddings querying, and the entire prototype-to-1K-document workflow fits on a laptop. pgvector is a strong second if you already have Postgres in the stack · one extension, no new infrastructure. Pinecone's serverless tier is the fastest path to a managed-cloud prototype if you want zero ops from day one.
Which vector database is the cheapest at scale?
Turbopuffer is the price disruptor in 2026 · serverless object-storage-backed architecture (S3 underneath) drops cost-per-million-vectors 10-100x vs traditional managed vector DBs at scale. pgvector is effectively free if you already pay for Postgres. Qdrant self-hosted on a single VM is the cheapest "real vector database" option if you want full feature parity. Pinecone's serverless tier is competitive at smaller scale but compounds cost beyond ~10M vectors.
Should I just use pgvector instead of a dedicated vector database?
If you already run Postgres in production and your vector workload is under ~5-10M vectors with relatively low QPS (under ~50 queries/second), pgvector is almost always the right answer. One database, one ops surface, transactional guarantees with your relational data. The break-points where you need to graduate to a dedicated vector DB: (1) above ~10M vectors with high recall requirements, (2) hybrid search with sparse + dense + filter combinations getting complex, (3) sustained QPS where Postgres connection pooling becomes a bottleneck, or (4) you need GPU-accelerated indexing.
How is Pinecone different from Weaviate in 2026?
Pinecone is a closed-source managed-cloud service · you can only use their hosted product, but the developer experience is the cleanest in the category and serverless pricing has narrowed the cost gap. Weaviate is open-source (BSD-3) with a managed cloud offering and self-host option, and bakes hybrid search (BM25 + dense vectors) and a GraphQL API in by default. Pick Pinecone if you want zero-ops with the simplest API. Pick Weaviate if you need on-prem option, hybrid search out-of-the-box, or freedom to migrate off the managed plane later.
What's the difference between Qdrant and Milvus?
Qdrant is Rust-built, single-binary, and optimized for operator simplicity · one process, easy to run on a single VM, fast cold starts, lean memory footprint. Milvus is the heaviest open-source option, Apache-licensed, distributed by design (separate query, data, index, coordinator nodes), and built for the largest workloads (billions of vectors, multi-tenant, GPU acceleration). Qdrant is what you reach for at 1M-100M vectors; Milvus is what you graduate to at 100M-10B+. The Zilliz managed service is the production path for Milvus.
What is Turbopuffer and why is it dramatically cheaper?
Turbopuffer is a serverless vector database that stores all data on object storage (S3) instead of attached SSDs, with intelligent caching for hot vectors. The architecture trades latency on cold queries (typically 200-500ms vs 10-50ms for traditional managed vector DBs) for radically lower storage cost · often 10-100x cheaper at the multi-million-vector scale. The right pick when you have a large vector corpus that's mostly cold (analytical workloads, long-tail RAG, archival semantic search) but cost matters more than P50 latency.
Can I switch vector databases after I've ingested millions of embeddings?
Technically yes, but expect to re-ingest. Embeddings themselves are portable (they're just float arrays), but the index structures, metadata schema, and query patterns differ across vendors. A 10M-vector migration typically takes 4-24 hours of compute plus 1-2 weeks of dual-write/dual-read validation to cut over safely. Plan for this from day one: keep your raw documents + embedding model versioned and reproducible, treat the vector DB as a rebuildable cache, and don't store ground-truth state inside the vector DB itself.
What's the most common mistake when picking a vector database?
Picking by benchmark instead of by ergonomic fit. Most vector DBs benchmark within 2-3x of each other on the workloads people actually run · the real constraints are (1) does this fit your existing stack (Postgres shop = pgvector; Python notebook prototyper = Chroma; managed-everything team = Pinecone), (2) does it support your filter + hybrid-search needs, and (3) what's the total cost of ownership including ops time, not just compute. The benchmark gap rarely matters; the ergonomic mismatch always does.
Related operator guide:
⚖️ 6 New California AI Laws · Operator GuideStuck choosing?
If you're between two of these and the benchmark charts aren't deciding it for you, text the actual constraint (existing stack, scale, ops appetite, hybrid search need) and I'll send back which way I'd lean. Operator opinion, not vendor pitch.
Text PJ · 858-461-8054