Every vector database vendor publishes a benchmark showing itself fastest at some combination of dimension count, dataset size and recall target, and none of those benchmarks tell you what you actually need to know: what breaks operationally at 3am, what the real bill looks like at your scale, and how much of your team's time it quietly consumes. The honest comparison isn't about raw query speed, most of these systems are fast enough for the overwhelming majority of real workloads, it's about the operational shape of each option and which shape matches your team.
Why raw speed isn't the right axis to compare on
Query latency benchmarks between Pinecone, Weaviate, Qdrant and Milvus at similar configurations typically differ by single-digit milliseconds to tens of milliseconds, a gap invisible to end users in almost any real product, since it's dwarfed by the LLM generation call that follows the retrieval step in a typical RAG pipeline. What actually differentiates these systems in production is everything the marketing pages undersell: how much engineering time it takes to keep the index healthy as data changes, what happens when you need to re-index or migrate, what the bill looks like once you're past the free tier and into real volume, and whether hybrid search, metadata filtering, and multi-tenancy are first-class features or something you bolt on yourself.
The comparison that matters
Here is what genuinely differs across the five options teams ask about most, based on how they behave in real production deployments rather than marketing benchmarks.
| Database | Deployment model | Cost model | Practical scale ceiling | Hybrid search | Operational burden |
|---|---|---|---|---|---|
| Pinecone | Fully managed only | Per-pod or serverless usage pricing, highest $/vector of the group | Very high, managed scaling handled by vendor | Built-in (sparse-dense hybrid) | Lowest; no infra to run, but zero self-hosting option ever |
| Weaviate | Managed or self-hosted | Managed tier usage-based; self-hosted is infra cost only | High; well-tested at hundreds of millions of vectors | Built-in (BM25 + vector) | Moderate self-hosted; low on managed tier |
| pgvector | Self-hosted (Postgres extension) | Just your existing Postgres infra cost | Good to roughly 10-50M vectors before index tuning gets hard | Requires combining with Postgres full-text search yourself | Low if you already run Postgres; high if you don't |
| Qdrant | Managed or self-hosted | Managed tier usage-based; self-hosted is infra cost only | High; designed for large-scale filtered search | Built-in (sparse-dense hybrid) | Moderate; lean, well-documented ops model |
| Milvus | Self-hosted or managed (Zilliz Cloud) | Managed tier usage-based; self-hosted needs a real ops team | Very high; built for billion-scale vector workloads | Built-in | Highest self-hosted burden; genuinely distributed system to run |
The case for pgvector: doing less, not more
If your team already runs Postgres, and the vast majority of B2B SaaS companies do, pgvector's real advantage isn't a technical feature, it's the system you don't have to add. Every extra managed service is another authentication setup, another billing relationship, another thing that can go down independently of your main database, another skill your team needs on call. pgvector keeps vectors, metadata and your regular relational data in one system with one set of backups, one set of access controls, and one query language. The tradeoff is real: past roughly 10-50 million vectors, index build and query performance tuning (HNSW parameter tuning specifically) becomes a genuine specialty, and pgvector doesn't have the purpose-built distributed architecture that lets Milvus or a well-configured Qdrant cluster scale past that point without a re-architecture. For most companies with tens of thousands to a few million documents, though, that ceiling is comfortably above what they'll ever need, and the simplicity wins by a wide margin.
The case for Pinecone: paying for zero operations
Pinecone's pricing is the highest per-vector cost of the group, and that's the honest tradeoff, not a hidden flaw: you're paying to never think about index rebuilds, sharding, or capacity planning, at any scale. For a team with no dedicated infrastructure engineer, or one whose infrastructure engineer has higher-priority problems than tuning a vector index, that premium is often cheaper than the alternative cost, an engineer's time diverted from product work to keep a self-hosted vector store healthy. Where Pinecone becomes a genuinely bad fit is when compliance or data residency requirements demand self-hosting, since it offers no self-hosted deployment option, or when volume grows large enough that the usage-based pricing becomes a board-level line item worth an internal team's time to replace.
Weaviate and Qdrant: the middle ground
Both sit between the two extremes: real vector-search-specific features (native hybrid search, good metadata filtering, multi-tenancy support) plus the option to self-host if you need to, without pgvector's ceiling or full-service-only lock-in. The practical difference between them for most teams is less about capability, both are solid, well-documented, and handle hybrid search and filtering natively, and more about ecosystem fit and existing team familiarity: Weaviate has leaned harder into an integrated ecosystem (built-in modules for embeddings, generative search hooks), while Qdrant has leaned toward a lean, fast, developer-friendly core with a smaller surface area to learn. Neither is the wrong choice if you're past pgvector's comfortable range but don't want Pinecone's fully-managed-only model or Milvus's heavier operational footprint.
When Milvus is the right, and only, answer
Milvus is built for a scale most companies never reach: hundreds of millions to billions of vectors, with a genuinely distributed architecture (separate components for indexing, querying, and storage that scale independently). That architecture is the right answer when you're actually at that scale, and real operational overkill, a distributed system with real failure modes to learn and monitor, when you're not. Teams reach for Milvus because a vendor benchmark impressed them at a scale they're nowhere near; the honest test is whether your current or 18-month-projected vector count is in the hundreds of millions, not whether Milvus's demo numbers looked good.
A decision framework, not a preference
The choice comes down to three real questions, answered honestly rather than aspirationally: what's your current and realistically-projected scale, does your team have infrastructure capacity to operate a self-hosted system well, and do you have a hard compliance requirement for data residency that rules out fully-managed options. Answer those three and the field usually narrows to one or two candidates before you've written a line of comparison code.
- Already run Postgres, under ~10-50M vectors, no dedicated infra team: pgvector, almost always the right default.
- No infra capacity to spare, budget allows it, scale could grow large: Pinecone, paying for zero operations.
- Past pgvector's comfortable range, want managed or self-hosted flexibility, need native hybrid search: Weaviate or Qdrant.
- Genuinely at (or firmly headed toward) hundreds of millions to billions of vectors, with real infra capacity: Milvus.
- Hard data residency requirement that rules out fully-managed-only vendors: self-hosted pgvector, Weaviate, Qdrant, or Milvus, not Pinecone.
