The Question
Your team is building a retrieval-augmented generation (RAG) system. You need to store document embeddings and retrieve the most semantically relevant chunks at query time. The vector database shortlist has six vendors on it because the team pulled a benchmark article from ANN-benchmarks, compared Pinecone, Weaviate, Qdrant, Milvus, Redis with vector extensions, and the PostgreSQL pgvector extension, and cannot reach consensus on which to select.
This is the standard vector database evaluation trap. ANN-benchmarks measures approximate nearest-neighbor search recall and throughput on standardized datasets at specific dimensionalities. It does not measure filtering performance when you need to search within a metadata-constrained subset of your corpus. It does not measure multi-tenancy isolation when you need to partition embeddings by customer or business unit. It does not measure update latency when your document corpus is updated continuously. It does not measure operational burden when your platform team is responsible for keeping the database running in production.
These are the criteria that actually determine whether your RAG system works correctly at enterprise scale — and they are absent from the benchmark comparisons that drive most evaluations.
Vector database selection is not a performance benchmark exercise — it is a tradeoff between operational simplicity, filtering capability, and scale that depends entirely on your RAG architecture and data characteristics.
Why This Matters Now
In 2024, a widely discussed production failure at a mid-size enterprise SaaS company illustrated the filtering performance problem directly. The company had deployed a RAG system using Pinecone as its vector database. The system was multi-tenant — it served multiple organizational customers from the same index, with metadata filters intended to ensure that Customer A's queries only retrieved Customer A's documents.
Under production load, the metadata filtering behavior under certain query conditions produced latency spikes that caused the system to fall back to returning results without filtering — a data isolation failure that exposed document fragments from one customer's corpus to another customer's queries. The root cause was a combination of how Pinecone's serverless tier handled metadata filter selectivity at the time and how the application had implemented the filtering logic.
The incident triggered a broader industry conversation about multi-tenancy in vector databases. Qdrant's payload filtering architecture — where filters are applied during the vector search process rather than as a post-search step — gained visibility as a technical approach that avoids this class of failure. Weaviate's tenant isolation features, introduced and matured through 2024, addressed similar concerns for teams needing hard data boundary enforcement between organizational units.
The lesson was not that Pinecone is an unacceptable choice — it is that vector database multi-tenancy architecture is a first-order selection criterion for enterprise RAG systems, and it requires explicit evaluation rather than assumptions based on general-purpose benchmark comparisons.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Infrastructure CURVE™ Report evaluated vector databases across seven dimensions: ANN search performance at enterprise dataset scales, metadata filtering performance under selectivity, multi-tenancy isolation architecture, update latency for continuously changing corpora, operational burden (managed vs. self-hosted), hybrid search capability (vector plus keyword), and total cost at scale.
Pinecone leads on operational simplicity and deployment speed. The managed service handles infrastructure, scaling, and availability transparently. The serverless tier eliminates capacity planning for variable workloads. For teams that need to ship a RAG application quickly without allocating MLOps engineering to database infrastructure, Pinecone removes friction better than any alternative.
Weaviate leads on hybrid search capability. The native BM25 + vector search combination — where a single query can simultaneously retrieve results based on keyword relevance and semantic similarity and merge the ranked lists — is the strongest implementation of hybrid retrieval available in the market. For enterprise knowledge bases where keyword precision matters alongside semantic recall, Weaviate's hybrid search is a meaningful differentiation.
Qdrant leads on filtering performance and multi-tenant architecture. Payload filtering applied during search — not after — means that metadata filters do not degrade search quality or create the data isolation risks associated with post-hoc filtering. The Rust implementation provides strong throughput performance. For RAG systems with complex multi-tenancy requirements or high metadata filter selectivity, Qdrant's architecture is the most technically sound.
pgvector leads on operational simplicity for PostgreSQL shops. If your organization already runs PostgreSQL, adding the pgvector extension adds vector search without introducing a new database technology to manage, secure, monitor, and operate. The operational integration story is unmatched for its target user.
The full vendor rankings are in the 2026 Stackcurve AI Infrastructure CURVE™ Report — free to download.
The Gap Most Buyers Miss
Enterprises evaluate vector databases on ANN benchmark performance and miss the architectural properties that determine production behavior.
The filtering architecture problem
Vector databases implement metadata filtering in fundamentally different ways, and the architecture has material consequences for production behavior. The two primary approaches are pre-filtering (filter the candidate set before running ANN search) and post-filtering (run ANN search across the full index, then filter results by metadata).
Pre-filtering approaches avoid scanning irrelevant data but can degrade ANN recall if the filter produces a small candidate set. Post-filtering approaches maintain ANN recall but require scanning more of the index and can return fewer results than requested when the filter eliminates a large portion of top-k results.
Qdrant's approach filters during the search process — integrating filter evaluation with graph traversal in its HNSW index implementation — which avoids the worst-case behaviors of both pure pre-filtering and pure post-filtering. This matters most when filter selectivity is high (most of your documents do not match the filter condition) or when data isolation correctness is a hard requirement.
Enterprises building multi-tenant RAG systems should explicitly ask each vendor: "How does your filtering implementation behave when a metadata filter matches less than 5% of index vectors?" The answer reveals the architecture and its production implications.
Update latency is invisible in benchmarks and critical in production
ANN benchmarks measure query performance on static datasets. Production RAG systems are rarely static. Documents are added, updated, and deleted continuously. The question of how quickly a new document becomes searchable after indexing — update latency — is absent from most benchmark comparisons and from most vendor evaluation criteria.
For enterprise knowledge bases with frequent document updates (help center articles, product documentation, internal wikis), update latency determines whether the RAG system reflects current information or lags behind reality. Pinecone's serverless tier and Weaviate both have managed update pipelines with subsecond-to-low-second update latency for most use cases. Qdrant's update performance is strong. pgvector at PostgreSQL scale begins to show update performance limitations as vector index sizes grow into the tens of millions.
pgvector has a practical scale ceiling that most evaluations understate
pgvector is the right answer for organizations with existing PostgreSQL infrastructure and moderate vector search volumes — up to a few million vectors with moderate query rates. At larger scales, two limitations become relevant. First, pgvector's HNSW index build time and memory requirements grow significantly with dataset size. Second, pgvector runs in the PostgreSQL process model, meaning heavy vector search query load competes for resources with transactional workloads on the same database. Organizations that have deployed pgvector for small-scale RAG and are planning to scale to tens of millions of vectors should evaluate whether a dedicated vector database is warranted before the migration cost becomes larger.
Questions Your Buying Team Should Be Asking
1. Is your RAG system multi-tenant, and if so, what are the data isolation requirements between tenants?
Multi-tenancy in RAG is not just an access control question — it is an architectural question about how the vector database partitions data and applies filters. Hard isolation requirements (regulatory or contractual requirements that tenant data cannot be co-mingled) favor a namespace-per-tenant or collection-per-tenant approach. Qdrant's multi-tenancy features and Weaviate's tenant isolation architecture were specifically designed for this use case. Pinecone's namespace feature provides logical isolation but shares underlying infrastructure. Understand your isolation requirement precisely before evaluating implementations.
2. Does your RAG application require hybrid search — simultaneous vector and keyword retrieval — and if so, how does each vendor implement it?
Hybrid search (combining semantic similarity with keyword relevance) significantly improves retrieval precision for many enterprise knowledge base use cases. Not all vector databases implement it with equal quality. Weaviate's BM25 + vector hybrid search with Reciprocal Rank Fusion is the most mature implementation. Qdrant added sparse vector support for hybrid search in 2024. Pinecone added hybrid search capability, but the implementation details differ from Weaviate's approach. If hybrid search is in your requirements, evaluate it explicitly with your actual document corpus and queries — benchmark results on synthetic data do not predict performance on your specific content.
3. What is the operational model your platform team can support — fully managed, self-hosted on Kubernetes, or PostgreSQL extension?
This question has a bigger impact on total cost of ownership than hardware specifications. Pinecone and Weaviate Cloud eliminate infrastructure operations entirely. Self-hosting Weaviate or Qdrant on Kubernetes requires MLOps engineering investment for deployment, monitoring, backup, and scaling. pgvector requires PostgreSQL operational expertise your team likely already has. Match the operational model to your team's capacity before committing to a vendor that requires operational investment you cannot staff.
4. What are your dataset scale and query volume projections over the next 24 months, and at what point does each vendor's pricing model break?
Pinecone's pricing scales with storage and query volume — it is cost-efficient at small to medium scale and becomes expensive at large scale. Self-hosted open-source alternatives (Weaviate, Qdrant) have near-zero software licensing cost but require engineering and infrastructure investment. pgvector's cost at small scale is essentially zero if PostgreSQL is already in place. Model the cost at your projected 24-month scale, not just your current scale, before making a selection.
5. How frequently does your document corpus change, and have you measured update latency from document ingest to searchability in each vendor's implementation?
If your RAG system indexes documents that change daily or continuously — support tickets, product documentation, news feeds, internal communications — update latency is a production correctness issue, not just a performance metric. Test update-to-searchability latency with your actual document pipeline on each vendor under load before selecting a platform. A vector database that performs well on static benchmark datasets but has 30-second update latency in your production data pipeline is not a production-ready solution for your use case.
The Stackcurve Take
The vector database market has matured significantly since 2023. The early-stage evaluation problem — choosing between a handful of immature options under time pressure — has been replaced by a more complex problem: choosing between capable options with meaningfully different architectural properties that are invisible in marketing materials and benchmark comparisons.
The decision framework is straightforward once you have mapped your requirements. Pinecone for operational simplicity and fast deployment without infrastructure management. Weaviate for hybrid search and open-source flexibility. Qdrant for multi-tenant filtering precision and performance-sensitive production applications. pgvector for teams with existing PostgreSQL infrastructure and moderate scale.
The enterprises that make the wrong choice typically do so because they evaluated the wrong criteria — optimizing for ANN benchmark recall on synthetic datasets while ignoring filtering architecture, update latency, and multi-tenancy isolation. Get the requirements right before you evaluate the implementations.
The 2026 Stackcurve AI Infrastructure CURVE™ Report covers vector database platforms including detailed evaluation of Pinecone, Weaviate, Qdrant, pgvector, Milvus, and Chroma. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.