4 Vector DBs Compared: Pinecone, Weaviate, Qdrant, pgvector on Enterprise RAG

The enterprise RAG vendor selection meeting always starts in the wrong place.

Someone pulls up a benchmark. The latency numbers go on the whiteboard. An hour later, the decision is made on p99 at 1M vectors, and nobody has asked what happens at the eighteen-month mark, when the index is 30M vectors, three teams depend on it, and the vendor just raised their per-query price.

Four names come up in almost every one of those meetings: Pinecone, Weaviate, Qdrant, and pgvector. They are not an exhaustive list. They are the shortlist that falls out of "we need production scale, we need metadata filtering, and the person sitting here has to be able to operate it on Monday." This post compares them on the four axes that actually move that Monday-morning decision, based on each vendor's public documentation.

The 10,000-foot view

Before the axes, a single table to orient:

Four choices, four different bets about where the operational pain will show up. Let's walk the axes.

Axis 1: Scaling model

Pinecone is managed-only. You cannot self-host it. In exchange, the capacity planning problem turns into a dropdown: pick a pod tier, pay the bill. The ceiling is high (Pinecone's public docs describe deployments into the billions of vectors), but every scale knob is behind their control plane. When you hit a performance issue at 2 AM, your only lever is to open a support ticket.

Weaviate publishes both a self-hosted binary and a managed cloud. Self-hosted scales horizontally by sharding across nodes, and the public docs describe deployments up to roughly 10 billion vectors. The cost: you own the Kubernetes. The payoff: you can see the memory profile, add nodes, debug the thing.

Qdrant is OSS first, and the Qdrant Cloud managed tier is a second option. Self-hosting is a single Rust binary that runs on a few hundred MB of RAM for small indexes and scales up by adding shards. The operational surface is smaller than Weaviate's, which is partly why Qdrant has been quietly eating mindshare in the self-host crowd.

pgvector is not a separate system. It is a PostgreSQL extension, which means your scaling model is your existing PostgreSQL scaling model. If you already run managed Postgres (RDS, Cloud SQL, Neon, Supabase), adding pgvector is a CREATE EXTENSION away. That is also its limit: pgvector performs well up to a few million vectors, but above roughly 5-10M vectors the HNSW index starts to feel the memory-boundedness of a single-node Postgres, and you are back to sharding Postgres, which is nobody's favorite afternoon.

Rule of thumb. If your projected 24-month vector count is under 5M, pgvector is almost always the cheapest answer. Over 50M, either Qdrant or Weaviate self-hosted will cost less than Pinecone. Between those, it depends on the team.

Axis 2: Index algorithm (and what you're allowed to tune)

Three of the four — Weaviate, Qdrant, and pgvector — use HNSW (Hierarchical Navigable Small World) as their primary ANN index. Pinecone runs its own proprietary stack (per Pinecone's docs, HNSW is not used). The differences are in which parameters you're allowed to touch.

pgvector has had HNSW since version 0.5.0 (shipped 2023), with two main tuning parameters: m (max connections per node) and ef_construction (candidate list size during build). At query time you set hnsw.ef_search. The public pgvector GitHub README documents all three. Simple, exposed, nothing hidden.

Qdrant's HNSW implementation is one of the fastest in the open benchmarks. It exposes m, ef_construct, and full_scan_threshold, and the engine does a lot of work behind the scenes to keep the index memory-mapped efficiently. Public benchmarks (the ANN Benchmarks project and the vendors' own) consistently put Qdrant in the top tier for recall-at-latency at 1M vectors.

Weaviate also uses HNSW with efConstruction and maxConnections, both documented in the public docs under "vector index parameters." Weaviate's differentiator is hybrid search: you can combine the vector score with BM25 keyword scores in the same query without wiring up a separate Elasticsearch, which matters for any RAG system where the question has named entities.

Pinecone is the outlier. Its index is a proprietary black box — Pinecone's documentation describes algorithm selection as automatic, and parameters like m, ef_construction, or ef_search are not exposed because the underlying engine is not HNSW to begin with. You pick a pod type, you get Pinecone's choice of tradeoff. For most teams that is fine. For a team that just saw their p99 regress and wants to buy back latency by lowering a search-time knob, it is not.

The implication is organizational, not technical. A team that likes knobs will outgrow Pinecone eventually. A team that wants the knobs invisible will outgrow self-hosted Qdrant eventually, in the opposite direction.

Axis 3: Metadata filtering (pre vs post)

This axis is where the actual RAG quality lives, and it is also where the vendors diverge hardest.

Every production RAG query looks something like: "give me the 10 nearest chunks, but only from documents owned by tenant_id=42, created after 2026-06-01, with status=published." The vector search is the fast part. The filter is the part that decides whether the result is correct.

Two design patterns exist:

Post-filter. Run the ANN search first, get top-K candidates, then apply the metadata filter. If the filter rejects most candidates, you get fewer than K results. Fix: fetch K×N and over-retrieve. This is what most naive systems do.

Pre-filter (filtered search). Push the filter into the HNSW graph traversal itself. The graph walk skips nodes that fail the filter. You get exactly K results that match the filter.

Qdrant's documentation is unusually explicit about this: its payload index supports filtered ANN where the filter is applied during graph traversal, not as a post-process. In practice, this means Qdrant degrades gracefully on highly-selective filters (tenant_id=rare_customer) where a post-filter engine would miss results.

Weaviate's documentation describes a similar approach with "filtered vector search" that integrates with its inverted index for the metadata side.

Pinecone supports metadata filtering, and their docs describe it as pre-filtered search, though the specific internal strategy isn't exposed (per Axis 2).

pgvector's situation is different: the filter is a WHERE clause in SQL, and the Postgres planner decides whether to use the HNSW index or a sequential scan. For narrow filters on indexed columns, Postgres can filter first and then do a brute-force vector scan over the small candidate set, which is often faster than HNSW over everything. For broad filters, it goes through the HNSW index. The developer doesn't pick the strategy; the query planner does.

If your RAG system has highly-selective tenant or permission filters, this axis matters more than latency. On a 100M-vector index where each query is restricted to one tenant's 10,000 vectors, a pre-filter engine returns the right 10 results. A post-filter engine might return 2 or 3 and silently drop the rest.

Axis 4: Pricing model

The axis that gets undercounted in the first meeting and overweighted in the second.

Pinecone is pay-per-use (serverless) or pay-per-pod (classic). Public pricing for serverless is listed per million read units, per million write units, and per GB stored. On a RAG system that does 100K queries/day against a 10M-vector index, the monthly bill at the time of writing lands in the mid-four-figures USD depending on query complexity. Predictable. Linear. Not cheap at scale.

Weaviate Cloud has a tiered pricing model (free sandbox, then paid tiers differentiated by SLA, replication, and dedicated-infrastructure guarantees). Self-hosted is infra cost only: your Kubernetes, your bandwidth, your on-call.

Qdrant Cloud publishes per-cluster pricing by instance size. Self-hosted is infra cost only, same as Weaviate. Qdrant's single-binary footprint tends to make self-host cheaper than Weaviate's at small scale.

pgvector has no license cost. The only cost is whatever Postgres is already costing you. If you have a managed Postgres, pgvector is approximately free. If you don't, pgvector isn't actually free; you just moved the vendor lock-in to the Postgres host.

The honest comparison: at the 1-10M vector scale, pgvector on an existing Postgres is often 10-30× cheaper than managed Pinecone. At the 100M+ scale, operated Qdrant or Weaviate self-hosted usually beats Pinecone by 2-5×, but with operational overhead that is not free. The crossover depends on how expensive your SRE hours are. Those hours never cost what the capacity plan said they would.

Three decision paths

With the four axes, a decision on vendor usually falls into one of three profiles.

SaaS startup, 1-10M vectors, no dedicated infra team. Pinecone serverless or pgvector. Pinecone if your Postgres is already stressed and you want zero additional operational surface. pgvector if your Postgres has headroom and your team knows SQL.

Internal RAG for a mid-size company, 10-100M vectors, Kubernetes team available. Qdrant self-hosted. The ceiling is high enough, the operational surface is small enough, and the filtered-search behavior is correct on tenant-scoped queries. Weaviate if you need hybrid search without wiring Elasticsearch next to it.

Embedded product (RAG-as-feature in a shipped app), unknown scale. Start with pgvector if your product already has Postgres. Move to Qdrant if you cross 10M. Do not start with Pinecone; the per-query cost at the embedded-feature scale tends to dominate the unit economics.

Why not Milvus, Chroma, LanceDB

Three honorable mentions that often come up:

• Milvus is excellent at the billions-of-vectors scale and has enterprise deployments at that tier. For the 1M-100M range this post targets, it is more operational weight than Qdrant for similar performance.
• Chroma is optimized for local development and small-scale deployments. Scales beyond a few million vectors are a stretch; this is a local-first system, not an enterprise one.
• LanceDB has a strong story for vector-plus-analytics workloads sitting on object storage. Worth a look if your RAG system wants to query vectors and OLAP columns in the same query. For pure RAG, the four above are more battle-tested.

What the book covers that this post doesn't

The book this post is condensed from spends most of its length on the pieces that matter before vendor selection:

• A 3-axis evaluation framework for enterprise RAG (faithfulness 50%, relevancy 25%, correctness 25%)
• The security and access-control design patterns (RBAC, pre-filter on tenant, prompt-injection detection)
• The information-classification matrix for deciding which internal docs to even put in a RAG system in the first place

Vendor selection is downstream of all three. If you pick the vendor first and the evaluation framework second, you tend to end up with the vendor your evaluation framework can't honestly measure. The chapter walks the full ordering in Japanese; this post is the vendor-level summary.

If you want the full version of the Context Engineering playbook (RAG, MCP, CLAUDE.md, Agentic RAG, with benchmarks), it's a book: Turning LLMs from Liars into Experts. Original benchmarks show a 4.6x quality gain across five context strategies, with 96 production-grade Python files published on GitHub.