I Tried Five Vector Databases. Here's What I'd Actually Use.
When we started building our RAG knowledge base, the first question was “which vector database?” I spent way too long reading comparison articles that were basically just marketing copy. So we tested five of them with our actual data and workload.
Here’s what we found. No sponsors, no affiliate links, just our experience with ~50,000 documents and ~200 queries per day.
The Contenders
- ChromaDB — Open source, self-hosted, Python-native
- Pinecone — Managed service, the “big name” in vector DBs
- Weaviate — Open source, self-hosted or cloud, GraphQL API
- Qdrant — Open source, Rust-based, fast
- pgvector — PostgreSQL extension, use your existing database
What We Tested
- Indexing speed: How fast can we embed and store 50,000 documents?
- Query latency: P50 and P99 for similarity search with various filters
- Relevance: Same queries, same embeddings — do different DBs return different results?
- Developer experience: How annoying is the setup, API, and debugging?
- Cost: Monthly cost for our workload
The Results (Summarized)
| Database | Index Time | P50 Query | P99 Query | Monthly Cost |
|---|---|---|---|---|
| ChromaDB | 45 min | 12ms | 85ms | ~$50 (EC2) |
| Pinecone | 30 min | 8ms | 35ms | ~$70 |
| Weaviate | 50 min | 15ms | 95ms | ~$60 (EC2) |
| Qdrant | 25 min | 6ms | 28ms | ~$50 (EC2) |
| pgvector | 90 min | 25ms | 180ms | ~$0 (existing DB) |
These numbers are for our specific workload. Your mileage will vary depending on data size, query patterns, and infrastructure.
My Honest Takes
ChromaDB — Where We Started
We chose ChromaDB initially because every RAG tutorial uses it. It’s dead simple to set up — pip install chromadb and you’re running. The Python API is clean and intuitive.
The problem: it’s not really built for production at scale. We hit memory issues around 40,000 documents on a 4GB instance. The persistence layer felt fragile — we had a few scares with data loss during restarts. And there’s no built-in replication or backup strategy.
For prototyping and small projects? Great. For production with uptime requirements? I’d look elsewhere.
Pinecone — The Easy Button
Pinecone is a managed service, which means you don’t manage infrastructure. For a team that doesn’t want to run databases, this is a big deal.
The API is simple, the dashboard is good, and it handles scaling automatically. Query latency was consistently low. The downside is cost — it’s more expensive than self-hosting, and the pricing model can surprise you if your usage patterns change. Also, your data leaves your infrastructure, which was a dealbreaker for one of our enterprise clients.
Qdrant — The One I’d Pick Today
Qdrant impressed us the most. Written in Rust, so it’s fast. The query latency was the lowest across the board. It supports filtering, payload storage, and has a solid Python client.
It can run embedded (for dev) or as a Docker container (for production). The documentation is excellent. It handles our 50k document corpus with room to grow, and the resource consumption is modest.
The only downside: smaller community than Pinecone or Weaviate. When you hit an edge case, Stack Overflow has fewer answers. But the Discord community is active and responsive.
Weaviate — Powerful But Complex
Weaviate does a lot — vectorization, GraphQL API, hybrid search, classification, all built in. But that power comes with complexity. The setup is more involved, the configuration has more knobs, and the learning curve is steeper.
If you need a vector database that also handles embedding generation and complex queries, Weaviate is worth considering. For “I just need to store and query vectors,” it’s overkill.
pgvector — The Surprising Contender
If you already have PostgreSQL, pgvector is remarkably practical. Install the extension, add a vector column, create an index. Done. No new infrastructure, no new backup strategy, no new monitoring.
Query latency is the highest of the five, and indexing is slow. But for workloads under 100k documents where you don’t need sub-10ms queries? The simplicity of using your existing database is hard to beat. We use pgvector for a smaller project where the team didn’t want to manage a separate vector store.
What Actually Matters
After all this testing, here’s what I think actually drives the decision:
Do you want managed or self-hosted? If managed → Pinecone. If self-hosted → Qdrant.
Do you already have PostgreSQL? And your dataset is under 100k docs? Just use pgvector. Seriously. Don’t over-engineer it.
Is this a prototype? ChromaDB. Get something working fast, migrate later if needed.
Do you need hybrid search built-in? Weaviate does this well out of the box. Others require more assembly.
The vector database matters less than your chunking strategy, retrieval pipeline, and prompt engineering. Don’t spend three weeks evaluating databases when you could spend that time improving your retrieval quality. Pick one that fits your infrastructure, and move on.