Which vector DB actually holds up when students start shipping?
Every RAG tutorial on the internet picks a vector database in line two of the notebook and never explains why. We got tired of that. Over the past two cohorts in our NLP & LLM Engineering course, we ran pgvector, Pinecone, Weaviate, and Qdrant through real capstone projects inside our RAG & Vector DB lab environment, with real data volumes and real embedding models. This post is what we learned.
Short version: there is no universal winner. But there are clear losers for specific situations, and most tutorials are steering people toward the wrong one for the wrong reasons.
Why most vector DB benchmarks miss the point
Synthetic benchmarks measure throughput on uniform random vectors with a fixed dimensionality and no metadata filters. Your production workload is not that. In our June 2025 LLM Engineering cohort, one student built a legal document retrieval system. Her Pinecone numbers looked great on 768-dim embeddings until she added a metadata filter on jurisdiction and date range. Query latency jumped 4x. Same data, same index, different query shape.
ANN Benchmarks is a fine starting point for understanding algorithm behavior. It tells you almost nothing about how a system behaves when you combine dense vector search with scalar filters, which is nearly every real RAG pipeline. Run benchmarks on your data, with your query patterns, using your actual embedding model. Anything else is trivia.
pgvector vs Pinecone: where the tradeoff actually lands
pgvector is genuinely good now. HNSW index support landed in version 0.5.0 and closed most of the latency gap that made it a non-starter in 2023. If you're already on PostgreSQL, the argument for bolting on a separate vector service gets weaker every quarter. We use pgvector in our Data Engineering for AI labs for exactly this reason: students learn to colocate vector search with transactional data, which simplifies the architecture considerably.
There's a real ceiling, though. Past roughly 2 to 3 million vectors, untuned pgvector queries get slow enough to matter. A student in our March 2025 MLOps cohort hit this wall hard when his product catalog grew from 800K to 4M embeddings after ingesting a new data source. The fix was tuning IVFFlat with lists = sqrt(n), which brought p95 latency back under 50ms. But it required actual DBA-level Postgres knowledge that not every team has. You also need to set hnsw.ef_search and m with some care, and most tutorials skip that part entirely.
Pinecone sidesteps all of it. No index tuning, no replica management, just an API call. For a team that needs managed simplicity and is already paying for cloud services, Pinecone is a completely defensible choice. The honest objection is the cost model: at $0.096 per 1M reads, a moderately active RAG pipeline accumulates real charges fast.
Qdrant vs Weaviate: why it wasn't a close call
Weaviate has one genuinely strong feature: native hybrid search that combines BM25 keyword scoring with dense vector similarity. If retrieval quality depends on exact term matching alongside semantic search, Weaviate's built-in hybrid mode is cleaner than rolling your own RRF fusion layer. Several students in our healthcare AI cohort used it for clinical note retrieval because medical terminology does not embed as cleanly as general language, and the hybrid approach recovered a lot of recall.
That said, Weaviate is heavy. Running it comfortably on a single node requires at least 4GB of heap, and its JVM-based architecture means garbage collection pauses show up in latency percentiles in a way that Qdrant's Rust core simply doesn't produce. That's not a knock on JVM in general. It's just physics.
Qdrant is what we run in our RAG & Vector DB lab environment. The Docker image is small, startup is fast, the Python client is clean, and on our L4 instances we consistently see p99 query latency under 10ms for filtered searches on 500K-vector collections. The reason that last number holds up is that Qdrant's payload filtering happens inside the HNSW traversal rather than as a post-filter step. Once you start combining vector search with attribute filters, that architectural choice matters a lot.
The Qdrant gRPC interface also plays well with our MLOps & AI Infrastructure students building production pipelines on Cloud Run, where connection overhead on high-throughput endpoints is a real concern.
What we actually run, and what we'd change
Our current stack: Qdrant for the RAG & Vector DB lab, pgvector for the Data Engineering lab (keeping things in Postgres teaches better habits for students who are building data pipelines), and Pinecone when a capstone project requires zero-ops deployment and the student is comfortable with the pricing.
We don't run Weaviate as a default lab environment anymore. The resource overhead doesn't fit the instance sizes we provision, and the hybrid search advantage only shows up for a subset of use cases. We still teach it because students encounter it in the industry, but we stopped recommending it as a starting point two cohorts ago.
If I were starting a new production RAG project today, here's where I land: Qdrant if I control the infrastructure, pgvector if the data already lives in Postgres and the collection stays under a few million vectors, Pinecone if the team has no interest in managing infra and the budget is there.
The worst choice is picking a vector database based on which one the tutorial you found last week happened to use. They're not interchangeable, and the differences show up exactly when your project stops being a demo.
