Vector Databases — Swarnim Tiwari

01

How is the database architected?

Vector databases look similar from the outside. Underneath, they make fundamentally different decisions about where data lives, how storage and compute relate, what languages they are written in, and what guarantees they offer. These decisions determine everything downstream: performance ceiling, operational complexity, failure modes, and the total cost at scale.

View

SaaS Only · Proprietary

Pinecone

Managed Knowledge Engine

Architecture

Serverless-first (since April 2026)

Decoupled storage / compute

Vector clustering on blob storage

Dedicated Read Nodes (GA)

BYOC (AWS, GCP, Azure)

01Serverless became the default architecture in April 2026 when pod-based indexes moved to legacy status. The storage engine was rebuilt around vector clustering on blob storage — frequently accessed vectors cluster into hot pages, cold vectors are evicted and retrieved on demand. Storage costs track collection size; compute costs track query volume. This is structurally different from the traditional model where you pay for provisioned capacity whether you use it or not.
02Storage and compute are fully decoupled layers. Reads, writes, and indexing each scale independently. During a traffic spike, read capacity increases without touching storage cost or indexing throughput. During quiet periods, idle compute costs zero. Zilliz's January 2026 pricing data and multiple independent analyses confirm this model produces the lowest baseline cost for bursty, unpredictable traffic compared to provisioned alternatives.
03BYOC (Bring Your Own Cloud) entered public preview in 2026 on AWS, GCP, and Azure. The Pinecone data plane runs inside the customer's own cloud account. Data never transits Pinecone's infrastructure. This is the architectural answer to data residency and compliance requirements that blocked enterprise adoption in regulated industries — healthcare, financial services, government — that cannot send embedding data to a third-party SaaS.
04Pinecone Inference integrates hosted embedding and reranking models directly into the ingestion and query pipeline. Developers send raw text; Pinecone generates embeddings before indexing or retrieval without an external API call. Pinecone Assistant extends this to production-grade chat and agentic applications, now with GPT-5 support as of mid-2026.
05Nexus and KnowQL (May 2026 Launch Week) reframe the product roadmap. Nexus is a knowledge layer for agentic workloads — structured storage and retrieval of agent memories, tool outputs, and context. KnowQL adds query semantics for agent context retrieval. The public positioning has shifted from "vector database" to "knowledge engine for AI agents." The architectural implication: Pinecone is building upward in the stack, not staying at infrastructure level.

Pinecone's architectural bet is that the right abstraction level for production AI teams is not a low-level vector store but a managed knowledge layer with embedded inference. The tradeoff is total vendor lock-in: no self-hosting, no data portability without a migration project, and pricing entirely controlled by one company. Teams that accept that tradeoff get the lowest operational burden in the category. Teams that cannot accept it have to look elsewhere.

Open Source · Go · BSD-3

Weaviate

Module-Based, AI-Native

Architecture

Go runtime

Modular vectorizer system

Schema-first collections

HFresh disk index (v1.38 GA)

Built-in MCP server (v1.38)

01Written in Go. Module-based plugin architecture: vectorizers, rerankers, and generative AI modules load as hot-swappable plugins. A developer configures a collection with an OpenAI, Cohere, or HuggingFace vectorizer and sends raw text at ingest time. Weaviate calls the embedding API internally. The embedding model is part of the collection configuration, not a separate external dependency the application manages.
02Schema-first design: every collection has a declared schema with typed properties, class names, and vectorizer assignments. This adds upfront configuration friction but enables GraphQL and gRPC query interfaces, enforces cross-collection reference integrity, and makes multi-tenancy isolation configurable at the schema level rather than in application code.
03Weaviate 1.38 (2026) shipped HFresh as a GA disk-based HNSW index. HFresh stores the HNSW graph on NVMe SSD rather than RAM, with only the navigation layer kept in memory. This enables collections 5 to 10 times the available RAM size without a machine upgrade or architectural change. It is the most direct answer to the memory cost problem at scale among the four databases compared here.
04Weaviate 1.38 also added a built-in MCP server. Weaviate collections are directly accessible as MCP tools without a custom wrapper or middleware layer. An AI agent queries Weaviate using the standard MCP client protocol — the same protocol it uses to call any other tool in its environment. This integration required zero changes on the agent side.
05Multi-modal support at the architecture level: text, image, audio, and video data can coexist in the same Weaviate collection using multi2vec module configurations. Different modalities are embedded by different vectorizers and stored in the same index. This is structurally different from how Pinecone, Milvus, and Qdrant handle multi-modal data: those stores hold vectors from any modality but do not generate embeddings from raw media natively.

Weaviate's architecture reflects a core product belief: the right abstraction is a knowledge graph, not a vector array. Schema, typed properties, cross-collection references, and AI-native modules make Weaviate the most semantically rich store in this comparison. The tradeoff is schema management overhead — schema changes on collections with millions of objects are operationally expensive. Teams that need flexibility to evolve their data model frequently should factor this into the evaluation.

Open Source · Go + C++ · Apache 2.0

Milvus

Disaggregated at Billion Scale

Architecture

Fully disaggregated layers

Woodpecker WAL (v2.6)

Milvus 3.0 kernel (beta)

Query / Data / Index nodes

Kubernetes-native

01Fully disaggregated architecture: proxy nodes handle routing, query nodes serve similarity searches, data nodes handle writes, and index nodes build indexes. These four node types run independently and scale independently on Kubernetes. When search latency spikes, add query nodes without touching data or index capacity. When ingestion throughput is the bottleneck, scale data nodes independently. No other vector database in this comparison offers this level of operational granularity.
02Milvus 2.6 retired the Kafka/Pulsar message bus dependency in favor of Woodpecker, a purpose-built write-ahead log designed specifically for Milvus workloads. For self-hosted teams, this removes the need to provision, configure, and operate a separate distributed streaming cluster alongside the vector database. Kafka at production scale is a team-sized maintenance commitment. Its removal is the most significant reduction in self-hosting complexity Milvus has shipped.
03Milvus 3.0 (beta, May 2026) introduced zero-copy data lake queries. The Milvus 3.0 kernel powers Zilliz Vector Lakebase — a decoupled storage-compute platform for analytics-scale vector workloads where data lives in S3-compatible object storage and compute is spun up on demand. This is Milvus entering the analytical query tier, not just the operational query tier.
04Object storage backend: MinIO or S3-compatible storage holds segment data persistently. etcd handles cluster coordination and metadata. The separation of storage from compute was architectural from day one — not a retrofit. This is why Milvus scales to tens of billions of vectors in production while maintaining durable storage independent of node failures.
05Zilliz Cloud is the managed Milvus offering. Zilliz claims 10x faster performance than self-hosted Milvus — an honest indicator of how difficult production self-hosting actually is. At the scales where Milvus is the right choice (100M+ to 10B+ vectors), teams typically adopt Zilliz Cloud unless they have dedicated MLOps capacity. Zilliz dropped storage pricing by 87% in January 2026, from $0.30/GB to approximately $0.04/GB.

Milvus was designed for scale from day one and it shows. The disaggregated architecture, the wide index selection, the Kubernetes-native deployment model — these reflect a team that understood enterprise-scale AI workloads before most other projects did. The tradeoff is real: if you are under 100M vectors, the operational complexity of Milvus exceeds the engineering benefit. The architecture that shines at 5B vectors is overkill at 5M.

Open Source · Rust · Apache 2.0

Qdrant

Rust-Native, Filter-First

Architecture

Rust runtime, single binary

Custom HNSW implementation

TurboQuant (v1.18)

One-stage payload filtering

On-disk storage mode

01Written in Rust. Single-binary deployment with no external dependencies — one Docker command starts a production-ready instance. There is no message bus to configure, no separate metadata store, no object storage to provision. This operational simplicity is not a constraint; it is a design goal. Qdrant's benchmark of how much complexity a production vector store actually requires is lower than all three alternatives in this comparison.
02Rust's memory model is the foundation of Qdrant's performance characteristics. Vectors are stored in contiguous memory blocks without garbage collection pauses or object header overhead. A Python-based equivalent storing the same vectors incurs 3 to 5 times the memory from Python objects and GC metadata. This is why Qdrant's self-hosted memory requirements are consistently lower than competitors at equivalent vector counts in independent benchmarks.
03Qdrant 1.17 (2026) added relevance feedback: given a result you like, find more like it. Query latency improvements also shipped in 1.17. Qdrant 1.18 (May 2026) shipped TurboQuant, a new quantization engine using fast Hadamard transform rotations from Google Research. Rotating vectors in high-dimensional space before scalar quantization reduces dimensional correlation, preserving recall at equivalent compression ratios better than direct scalar quantization.
04Quantization suite in one database: scalar quantization (4x memory reduction, less than 1% accuracy loss), product quantization (32x compression for very large collections), binary quantization (extreme memory efficiency at higher recall penalty). Quantization is configurable per collection rather than a global database setting. Different collections with different recall requirements coexist in the same Qdrant deployment with different quantization strategies.
05On-disk storage mode allows storing vectors on disk with the payload index in memory. A single Qdrant node handles collections larger than available RAM without DiskANN's preprocessing complexity. This is the self-hosted answer to the memory-cost problem at intermediate scale — not as compressed as DiskANN but significantly simpler to operate. Combined with TurboQuant, Qdrant's memory efficiency at 100M to 500M vectors is the most practical self-hosted story in this comparison.

Qdrant's architecture is the clearest articulation of a specific thesis: a vector database should be fast, simple to operate, and deeply configurable at the storage layer. It does not try to be a knowledge graph (Weaviate), a distributed compute platform (Milvus), or a managed cloud product (Pinecone). It is a high-performance vector store with an exceptional filtering implementation, written in a language that makes the performance claims structurally credible rather than benchmark-specific.

02

How do they index vectors and find nearest neighbors?

HNSW is the dominant approximate nearest neighbor index in production vector databases, but its implementation details vary enormously. How index parameters are tuned, whether the index fits in RAM, how recall and latency are traded off, and what alternative index types exist when HNSW is not the right fit — these differences separate production deployments from demos.

View

SaaS Only · Proprietary

Pinecone

Auto-Tuned, Abstracted

Index Types

HNSW (internal, auto-tuned)

Vector clustering on blob

Pinecone Inference (hosted)

Real-time indexing

Dedicated Read Nodes

01HNSW is the underlying algorithm but its parameters are abstracted. Developers do not set ef_construction, M value, or ef at query time. Pinecone auto-tunes index parameters based on observed data distribution. The default behavior is a well-tuned index for the median use case. The tradeoff is that teams with specific recall-latency requirements — who would manually tune ef to 512 for high-recall queries against a time-sensitive collection — cannot do so in Pinecone.
02Serverless cold start is the most-cited production limitation. After a period of inactivity, the first query can take 200ms to 2000ms while the system retrieves vector pages from blob storage and warms the navigation cache. For real-time applications — chat, recommendation feeds, search-as-you-type — this is a disqualifying latency spike. Pinecone's documentation recommends Dedicated Read Nodes or pod-based indexes for latency-sensitive workloads.
03Dedicated Read Nodes (DRN) are now GA as of 2026. DRN adds read-only nodes for sustained high-QPS traffic without the cold start problem. Pricing is per-node-hour rather than per-query. For traffic patterns where query volume is predictable and high, DRN is the operationally correct choice. For bursty traffic, serverless remains the cost-optimal choice and the cold start is an acceptable latency spike on occasional first queries.
04Real-time indexing is a documented architectural strength for agentic workloads. When an agent writes a memory entry, it is immediately queryable without a manual index rebuild step or an ingestion-to-queryable lag. Competing systems — particularly Milvus in self-hosted configuration — have a segment-sealing delay between ingestion and query availability. For agent memory systems that need to retrieve recently stored context within the same agent run, this matters.
05Pinecone Inference hosts embedding and reranking models. A developer sends raw text to a Pinecone upsert call; Pinecone generates the embedding before indexing. No embedding model client code, no external API latency in the critical ingestion path, no synchronization between the embedding model version and the stored vectors. For teams who want fewer moving parts in the ingestion pipeline, this integration is a meaningful simplification.

The abstraction of index parameters is Pinecone's most debated design decision. Auto-tuning is genuinely helpful for most teams who would misconfigure HNSW parameters anyway. It becomes a limitation for teams running high-precision recall experiments or latency-sensitive applications that need to tune ef per query. At scale, the inability to control recall-latency at query time is a real constraint that teams discover after adopting the managed service.

Open Source · Go · BSD-3

Weaviate

HNSW + HFresh + Flat

Index Types

HNSW (in-memory)

HFresh (disk-based, v1.38 GA)

Flat (exact, small collections)

Inverted index (BM25, native)

Rotational quantization (RQ)

01HNSW is the primary vector index, running in memory with full configurability. Developers set ef_construction at collection creation time (controls index quality, higher is better recall at cost of build time) and ef at query time (controls the search beam width). A collection can be queried with ef=64 for low-latency use cases and ef=512 for high-recall batch processing using the same index without rebuilding.
02HFresh (v1.38, GA 2026) is a disk-based HNSW implementation. The HNSW graph is stored on NVMe SSD; only the upper navigation layers are kept in RAM. For collections where the full HNSW graph does not fit in available memory, HFresh enables search without spinning up a larger machine. Query latency increases compared to fully in-memory HNSW — NVMe random reads are slower than DRAM — but remains sub-100ms for most production RAG workloads.
03Flat index for small collections: exact nearest neighbor search with 100% guaranteed recall. For collections under 10,000 vectors — developer testing, small knowledge bases, per-user personalization shards in a multi-tenant deployment — flat index eliminates the approximation error of HNSW entirely. The index type is declared at collection creation time and can be changed by recreating the collection.
04Rotational quantization (RQ) shipped in 2026 for multi-tenant workloads. In a Weaviate deployment with many small tenants sharing a cluster, per-tenant recall quality can degrade with standard scalar quantization because the optimal quantization parameters differ across tenants. RQ applies tenant-specific rotation matrices before quantization, preserving per-tenant recall quality without issuing each tenant a dedicated node.
05Inverted indexes for BM25 are built alongside vector indexes during the same ingestion pass. Text properties configured for keyword search generate both the dense vector embedding (via the vectorizer module) and the BM25 token index at write time. There is no separate keyword ingestion step; both indexes are maintained transactionally with the same write operation, keeping them in sync without developer-managed synchronization.

HFresh is the most practically significant new capability Weaviate shipped in 2026 for teams running at scale. Before HFresh, teams whose collections outgrew available RAM had to choose between upgrading hardware or migrating to a distributed deployment. HFresh provides a third option: disk-backed HNSW on existing hardware at the cost of some query latency. For many workloads at 100M to 500M vectors, that tradeoff is clearly worth taking.

Open Source · Go + C++ · Apache 2.0

Milvus

Widest Index Selection

Index Types

HNSW

IVF_FLAT / IVF_PQ / IVF_SQ8

DiskANN

CAGRA (GPU)

Async index building

01Widest index selection of the four databases. IVF (Inverted File Index) partitions the vector space into Voronoi cells and searches the nearest cells. IVF_FLAT provides exact search within those cells. IVF_PQ adds product quantization to reduce memory at the cost of recall. IVF_SQ8 applies scalar quantization. The choice between IVF variants is a direct tradeoff between memory consumption, build time, and recall at query time — all tunable without changing the data model.
02DiskANN stores the index graph on disk with a compressed in-memory representation for navigation. For collections at 1B+ vectors, the memory requirement for a full in-memory HNSW index is measured in terabytes and costs accordingly. DiskANN reduces in-memory requirements by 5 to 10 times while maintaining competitive recall and latency. This makes billion-vector self-hosting economically viable where pure in-memory approaches would not be.
03GPU indexes: CAGRA and IVF_FLAT on GPU. For workloads with a GPU-enabled node available — recommendation systems processing thousands of queries per second, batch embedding search pipelines — GPU indexing delivers approximately 4x query throughput over CPU-equivalent configurations at the same recall. Milvus is the only open-source vector database in this comparison with production-mature GPU index support.
04Index building runs on dedicated index nodes asynchronously from query and write nodes. Large collections can be re-indexed without taking search offline. When a team discovers in production that their index parameters were misconfigured — a common scenario — Milvus allows correcting the error without a maintenance window. This operational flexibility is a significant advantage over systems where reindexing blocks queries.
05A documented production gotcha: if you return scalar fields alongside vectors in query results, Milvus performs a secondary fetch from object storage. A community benchmark found QPS drops approximately 45% when 12 scalar fields are returned versus only document IDs. RAG pipelines that need to return chunk text alongside vector similarity scores need to factor this into their performance modeling. Returning IDs and doing a secondary lookup in a relational database can outperform Milvus's native field retrieval for read-heavy pipelines.

Milvus's index diversity is a genuine engineering advantage, not feature bloat. Different workloads have fundamentally different index requirements: a real-time recommendation system with strict latency budgets needs HNSW; a batch analytics pipeline processing billions of vectors overnight needs IVF_PQ for memory efficiency; a GPU-accelerated inference cluster needs CAGRA. Milvus is the only open-source option where all three use cases share one database without compromise.

Open Source · Rust · Apache 2.0

Qdrant

Custom HNSW + TurboQuant

Index Types

Custom HNSW (filter-aware)

TurboQuant (v1.18)

Scalar quantization (4x)

Product quantization (32x)

Binary quantization

01Qdrant's HNSW implementation is custom-built rather than adapted from an existing library. The critical difference: standard HNSW ignores payload (metadata) during graph traversal and filters candidates afterward. Post-filtering degrades recall significantly when filters are selective — if only 1% of vectors match a filter condition, post-filtering must retrieve 100x more candidates to return k results at target recall. Qdrant's implementation integrates payload conditions into the traversal itself, maintaining recall under aggressive filtering without retrieving unnecessary candidates.
02TurboQuant (v1.18, May 2026) uses fast Hadamard transform rotations developed from Google Research methodology before applying scalar quantization. Rotating vectors in high-dimensional space before quantization reduces inter-dimensional correlation, which is the primary source of quantization recall loss in traditional scalar quantization. The result: roughly 8x vector compression at better recall preservation than previous quantization approaches at equivalent compression ratios.
03Scalar quantization: 4x memory reduction with less than 1% accuracy loss in Qdrant's published benchmarks at standard embedding dimensions. For a collection using 50GB of RAM for full-precision vectors, scalar quantization brings this to approximately 12.5GB with negligible recall difference. This is the first quantization choice for most teams: the memory savings are significant and the recall penalty is small enough to be invisible to end users.
04Product quantization enables 32x compression for very large collections where scalar quantization still leaves too much data in RAM. PQ divides each vector into sub-vectors and compresses each independently using a learned codebook. The codebook must be trained on a representative sample of the collection — a one-time offline operation — before PQ can be applied. The recall penalty is larger than scalar quantization and varies by collection; teams should benchmark on their specific data before committing.
05ef parameter is fully exposed at query time and per-request configurable. The same Qdrant collection can be queried with ef=64 for low-latency search in a recommendation feed and ef=512 for high-recall search in a compliance document retrieval system. No index rebuild, no collection duplication, no separate endpoints. This flexibility is available because Qdrant surfaces the underlying HNSW parameter rather than abstracting it away as Pinecone does.

The combination of filter-aware HNSW traversal and TurboQuant puts Qdrant in a unique position for filtered RAG workloads. Most production RAG systems apply filters — date ranges, document types, tenant IDs, access control conditions. In systems where filtered search is the dominant query pattern, Qdrant's architectural advantage in maintaining recall under filtering is not marginal. It is the difference between a retrieval system that works and one that silently degrades as filter conditions become more specific.

03

How does hybrid search work?

Pure vector similarity misses exact keyword matches. Pure keyword search misses semantic meaning. Production retrieval systems need both. Hybrid search — combining dense vector similarity with sparse keyword scoring — is now the standard architecture for high-quality RAG pipelines, but each database implements it differently and the implementation details determine how easy it is to tune and how well it scales.

View

SaaS Only · Proprietary

Pinecone

Sparse-Dense, Single Query

Hybrid Stack

Native sparse + dense

Alpha blend parameter

SPLADE compatible

Full-text search (preview)

Pinecone Inference reranking

01Pinecone's hybrid search sends a dense vector and a sparse vector in the same query object. Both are indexed in the same Pinecone index under the same namespace. Results are ranked by a weighted combination of cosine similarity (dense) and dot product (sparse). The developer controls the blend with a single alpha parameter: 0.0 is pure keyword, 1.0 is pure semantic. No separate infrastructure, no query merging code, no two-step retrieval pipeline.
02Alpha is tunable per query, not fixed at index creation time. A factual entity lookup ("What is Anthropic's API rate limit?") benefits from alpha close to 0 — the exact keyword "rate limit" and "Anthropic" matter more than semantic similarity. A conceptual question ("how do language models handle uncertainty?") benefits from alpha close to 1 — semantic meaning matters more than exact phrase matching. Per-query alpha tuning lets one index serve both patterns.
03Pinecone does not generate sparse vectors automatically from text as of mid-2026. Developers provide precomputed sparse representations, typically from SPLADE or BM25 encoders run externally. The dense embedding and sparse encoding are two separate preprocessing steps before upsert. This adds an external dependency but gives full control over the sparse encoding strategy — teams can use SPLADE for learned sparse representations or BM25 for simple frequency-based ones.
04Full-text search entered public preview in 2025-2026. When GA, it will add native BM25 indexing so Pinecone generates sparse vectors from raw text automatically at ingest time — eliminating the external sparse encoder dependency. Until GA, teams need to decide whether to use external sparse encoders now or wait for the native capability and accept the current two-step pipeline.
05Pinecone Inference includes reranking models. After the hybrid retrieval returns the top-k candidates, a reranking call reorders them using a cross-encoder model that reads the full query and document text together. Two-stage retrieval (retrieve then rerank) is the standard pattern for high-quality RAG. Having both stages in one managed service reduces the number of external services in the production stack.

Pinecone's hybrid search is operationally the simplest in this comparison once the sparse encoder is set up. One index, one query object, one alpha parameter, one results list. The main friction is the external sparse encoder: teams need to choose one, run it at both ingest and query time, and ensure the encoder version matches between the two. When full-text search reaches GA, that friction disappears and Pinecone's hybrid story becomes the most developer-friendly in the group.

Open Source · Go · BSD-3

Weaviate

Unified Query Planner

Hybrid Stack

Unified planner (parallel paths)

RelativeScoreFusion

RRF (standard fusion)

Native BM25 inverted index

Auto-embedding at query time

01Weaviate's hybrid search is structurally different from the others in this comparison. A single GraphQL or gRPC query with a hybrid block executes both the vector search path and the BM25 keyword path in parallel inside a unified query planner. There is no developer-managed orchestration of two searches — Weaviate handles the parallel execution, result fusion, and unified ranking internally. This is the most operationally transparent hybrid implementation in the comparison.
02RelativeScoreFusion is Weaviate's proprietary fusion algorithm, distinct from standard Reciprocal Rank Fusion. RRF discards score magnitude and uses only rank positions — a result at rank 1 always contributes the same weight regardless of how strong the match was. RelativeScoreFusion preserves the original distance and score distributions from both search paths before merging. When the vector search is highly confident and the keyword match is weak, RSF reflects that in the final ranking. RRF does not.
03BM25 inverted indexes are built alongside vector indexes during the same ingestion pass. A text property marked for keyword search generates both an embedding (via the vectorizer module) and a BM25 token index at write time. The two indexes stay in sync automatically. There is no separate keyword ingestion pipeline, no risk of the keyword index being behind the vector index, no ETL job to maintain.
04Auto-embedding at query time: send a text string in the nearText parameter and Weaviate calls the configured vectorizer to embed it before executing the vector search. The hybrid query becomes one GraphQL request with a text string, a keyword string, and a fusion weight. No embedding client code in the application layer. This is the most complete "send raw text, get ranked results" developer experience in this comparison.
05Alpha weight in Weaviate's hybrid query ranges from 0 to 1, identical to Pinecone's convention. Cross-encoder reranking is available via the reranker module, which accepts the fused candidate list and reranks using a configured model. The module system means reranker models can be upgraded without changing the application query code — swap the module configuration, not the query logic.

Weaviate does one thing better than any other database in this comparison: hybrid search. The unified query planner, the native BM25 inverted index built at ingest time, the auto-embedding at query time, and RelativeScoreFusion combining results more accurately than RRF — every component is designed together rather than assembled from parts. For teams where hybrid retrieval quality is the primary evaluation criterion, Weaviate is the clear architectural choice.

Open Source · Go + C++ · Apache 2.0

Milvus

Multi-Vector Fields + BM25 fn

Hybrid Stack

Multi-vector field search

Sparse vector index

BM25 function (native)

RRF and weighted sum fusion

Elasticsearch migration path

01Milvus implements hybrid search through multi-vector fields. A collection schema defines both a dense vector field (for HNSW or IVF indexing) and a sparse vector field (for keyword representation). A hybrid query sends a dense vector and a sparse vector simultaneously and receives results fused from both fields. The schema approach is more verbose than single-index hybrid but enables searching multiple dense vector fields in the same query — a capability relevant for multi-modal or multi-language retrieval systems.
02BM25 function (2024-2025, production-mature) enables automatic sparse encoding from text fields. Define a BM25 function on a text field in the collection schema; Milvus generates and stores the sparse BM25 representation at ingest time without an external sparse encoder. This eliminates the preprocessing dependency that Pinecone's hybrid search currently requires. The BM25 function uses Milvus-internal tokenization — teams with specialized tokenization requirements (CJK languages, domain-specific vocabulary) need to verify coverage.
03Sparse vector index uses an inverted index structure internally, appropriate for the high-dimensional sparse distributions that BM25 and SPLADE representations produce. Sparse vectors with thousands of non-zero dimensions are stored efficiently; standard HNSW would be inappropriate for this representation. The dedicated sparse index type is a sign that Milvus treats sparse vectors as a first-class data type rather than a workaround.
04RRF and weighted sum are the available fusion strategies. Weighted sum allows assigning different scalar weights to the dense and sparse search scores. Teams migrating from pure keyword search (Elasticsearch, OpenSearch) typically start with a high sparse weight and progressively shift toward dense as they validate semantic search quality on their data. The weighted sum fusion makes this progressive migration tunable without changing the index schema.
05Milvus is the most natural migration path for teams moving from Elasticsearch or OpenSearch to a vector-capable system. The inverted index architecture, familiar BM25 scoring, and the ability to maintain purely keyword indexes alongside vector indexes without a separate infrastructure component map well onto the mental model of teams experienced with Lucene-based search. Weaviate offers better out-of-the-box hybrid quality; Milvus offers a more familiar operational model for search infrastructure teams.

Milvus's hybrid search implementation is the most flexible in this comparison for teams with complex retrieval requirements: multi-vector queries, custom sparse encoders, and weighted fusion across more than two retrieval paths. The tradeoff is operational complexity — configuring multi-vector schemas, managing both dense and sparse ingestion, and tuning fusion weights requires more engineering investment than Weaviate's unified planner. The investment is justified for teams at scale with dedicated search engineering capacity.

Open Source · Rust · Apache 2.0

Qdrant

Prefetch + RRF + Custom Combine

Hybrid Stack

Prefetch mechanism

Sparse vectors (native field)

RRF fusion

Custom Combiner (arbitrary)

Cross-encoder reranking

01Qdrant hybrid search uses the prefetch mechanism: execute a dense vector search and a sparse vector search independently, collect the top candidates from each, then fuse the combined candidate set with a configured fusion algorithm. This differs from Weaviate's unified planner — Qdrant explicitly runs two separate searches before fusion. The explicit two-stage model makes each stage independently observable and tunable, which is valuable for debugging retrieval quality issues in production.
02Sparse vectors are a native field type with a dedicated index structure. SPLADE and BM25 sparse encodings are first-class alongside dense vectors in the same point. A Qdrant point can carry a dense 1536-dimensional embedding and a sparse 30000-dimensional SPLADE encoding in the same document. Both are indexed and both are queryable from the same request. No schema migration, no separate collection for sparse data.
03RRF (Reciprocal Rank Fusion) is the default fusion strategy, well-calibrated for the common case where dense and sparse scores are not on the same scale. Custom Combiner enables arbitrary weighted combinations of any number of retrieval paths — dense vector, sparse vector, and a third domain-specific embedding in the same collection if needed. This is the most flexible fusion interface in this comparison and the most relevant for teams building multi-representation retrieval systems.
04Fusion configuration is per-request, not fixed at collection creation time. The same Qdrant collection queries with pure dense (no sparse prefetch), pure sparse (no dense prefetch), or any hybrid configuration on a request-by-request basis. A single Qdrant deployment serves multiple application use cases with different retrieval strategies without maintaining separate collections for each strategy.
05Cross-encoder reranking support: after prefetch and fusion, send the top candidates to a reranking model. Qdrant collects candidates efficiently across multiple retrieval strategies in the prefetch step; the reranker is plugged in externally and receives the fused candidate list. This two-stage architecture — broad retrieval via ANN then precision reranking via cross-encoder — is the standard pattern for highest-quality production RAG and Qdrant's prefetch mechanism is designed to feed it well.

Qdrant's prefetch-based hybrid architecture is the most transparent in this comparison: every stage is explicit, every result set is inspectable, and every fusion configuration is a runtime parameter rather than a compile-time schema decision. For teams where the retrieval pipeline itself is a product — where engineers are actively tuning and A/B testing different retrieval strategies — Qdrant's explicit model is more maintainable than Weaviate's unified planner, even if it requires slightly more orchestration code per query.

04

How does metadata filtering work?

Similarity alone is not enough for production retrieval. Most real queries add constraints: only documents from this user, this date range, this document type, this access tier. How those constraints are evaluated — before ANN search, after ANN search, or integrated into the search traversal — determines whether filtering degrades recall and by how much. This is one of the least-discussed but most consequential differences between vector databases.

View

SaaS Only · Proprietary

Pinecone

Metadata Filter DSL

Filter System

JSON filter language

$eq, $ne, $in, $nin operators

$gt, $lt, $gte, $lte ranges

$and, $or logical ops

Namespace isolation

01Metadata is stored alongside vectors in the same index. Filters are expressed as JSON objects using a MongoDB-style DSL with operators: $eq for equality, $in for set membership, $gt/$lt/$gte/$lte for range conditions, $and/$or for logical combinations. A query returning only documents from a specific user, in a specific date range, of a specific type uses one filter object combining all three conditions.
02Namespace isolation is a first-class architectural primitive in Pinecone. Namespaces partition an index into disjoint segments. All operations — upsert, query, delete — are scoped to one namespace. For multi-tenant applications where each tenant's data must be completely isolated, namespaces provide that isolation without separate indexes. Querying across namespaces is not supported by design — namespace isolation is strict.
03Scalar field cardinality affects filter performance. High-cardinality metadata fields (unique IDs, timestamps with millisecond precision) with equality filters are efficient because the filter eliminates nearly all candidates immediately. Low-cardinality fields (boolean flags, enum values) with selective filters require scanning more candidates before k results are found. Pinecone's documentation recommends against using high-cardinality numeric fields as filters when exact string matching on lower-cardinality fields would serve the same purpose.
04Metadata is stored in-memory for fast filter evaluation. Adding many metadata fields per vector increases RAM consumption independent of the vector dimensions. Teams storing verbose metadata — long JSON objects, many nested fields, redundant information — on tens of millions of vectors can hit memory limits before hitting the vector storage limit. The recommendation is to keep metadata minimal: only fields that will appear in filter conditions.
05Nested filter operators are supported: $and containing multiple $or blocks, $or containing nested $and conditions. Complex access control policies expressed as nested role-permission conditions are expressible in a single filter object without preprocessing. This is relevant for enterprise RAG systems where every query must enforce document-level access control derived from the requesting user's role and organization membership.

Pinecone's filter system is well-designed for the most common production use cases: tenant isolation via namespaces, date range filtering, type and category filtering. The limitation surfaces when filters become highly selective (returning less than 1% of the collection) combined with high top-k requirements — recall degrades because the internal post-filter approach must scan more candidates. Teams hitting this pattern on Pinecone are candidates for Qdrant's one-stage payload filtering architecture.

Open Source · Go · BSD-3

Weaviate

GraphQL Where + Cross-Reference

Filter System

GraphQL where clause

Cross-collection filtering

Geo-distance / Geo-polygon

Null / count filters

Multi-tenant isolation

01Filters are expressed as GraphQL where clauses embedded in the query. The schema-first design means every filterable field has a declared type — string, int, date, boolean, geo-coordinates, text — and the available operators depend on the declared type. A date field supports dateRange operators; a geo field supports geoRange operators; a string field supports like, Equal, or Contains. Type safety at the filter level prevents a category of production bugs where filter logic silently returns wrong results due to type coercion.
02Cross-collection filtering is a unique capability that comes from Weaviate's knowledge graph architecture. A query on a Document collection can filter on properties of a referenced Author object in a separate collection — filtering for documents written by authors who joined after a certain date, for example. This graph traversal in a filter condition is not available in any other vector database in this comparison and reflects the relational model that Weaviate's schema system enables.
03Geo-distance filtering is native. A query can find the k most similar documents within 50km of a geographic coordinate. For location-aware RAG systems — local business recommendations, geographic document retrieval, location-tagged knowledge bases — geo filtering combines with vector similarity in a single query without a separate spatial database. Milvus has some geo support; Pinecone and Qdrant require preprocessing geographic conditions into metadata fields.
04Null property filtering: find objects where a specific property is not set, or where a specific property count exceeds a threshold. For collections with optional metadata — documents where some have authors and others do not — null filters enable querying incomplete records without scanning them all. This is a niche but real production requirement that generic metadata filter systems handle inconsistently.
05Multi-tenancy is a first-class feature with schema-level tenant isolation. A Weaviate collection configured for multi-tenancy maintains completely separate HNSW indexes per tenant — not one index with a tenant ID filter, but physically separate index shards. This prevents one tenant's query patterns from affecting another tenant's recall or latency. The tradeoff is memory overhead proportional to the number of active tenants rather than total vector count.

Weaviate's filter system is the richest in semantic expressiveness: typed property filters, cross-collection graph traversal, geo conditions, null checks, and multi-tenant physical isolation. The schema-first requirement is the entry cost for this expressiveness. Teams that define their schema carefully upfront benefit from type-safe filters and structured query interfaces. Teams that need to add new filterable properties frequently will encounter schema migration overhead that the schema-free alternatives do not have.

Open Source · Go + C++ · Apache 2.0

Milvus

Boolean Expression DSL

Filter System

Boolean expression DSL

Scalar field inverted index

AND / OR / NOT / IN / LIKE

JSON field filtering

Partition key isolation

01Milvus filters use a boolean expression DSL passed as a string: id in [1,2,3], category == "finance" and date >= 20240101. The string syntax is familiar to developers from SQL backgrounds and flexible for complex conditions. The expression is parsed and compiled at query time rather than validated against a schema — which means invalid filter expressions fail at runtime rather than at development time, a debugging experience worse than Weaviate's typed GraphQL approach.
02Scalar field inverted indexes are buildable on filterable fields. Without an explicit scalar index, filter evaluation requires scanning segment-level data for every candidate. With a scalar index, filtering narrows candidates before vector search begins. Teams should explicitly create scalar indexes on high-selectivity fields used in common filter conditions. Unlike HNSW indexes (built automatically at collection creation), scalar indexes require a manual index creation call — a step that is easy to miss and produces large performance differences when omitted.
03JSON field filtering: store arbitrary JSON blobs as a field and apply dot-notation filters on nested JSON properties at query time. Milvus extracts the JSON field during filtering without requiring nested properties to be declared in the schema. This is the most flexible metadata storage in this comparison for teams with variable-schema objects — product catalogs, documents with heterogeneous attributes, user profiles with optional fields — where declaring every possible property in a schema is impractical.
04Partition key: designate a string or integer field as a partition key when creating a collection. All writes route to the partition matching the key value; queries with that key in the filter scan only the matching partition. For tenant isolation patterns — partition key is tenant_id — this reduces query scope to the relevant partition and prevents cross-tenant data leakage. Partition keys at the collection level are a simpler multi-tenancy implementation than Weaviate's per-tenant HNSW shards.
05Milvus filter performance at billion-scale depends heavily on whether scalar indexes are in place for the filter fields and whether the distribution of filter values maps well to segment boundaries. A query filtering by a common value shared by 30% of all vectors scans 30% of segments before ANN search. At billion-vector scale, that is a meaningful scan. Teams running high-frequency filtered queries at this scale should profile which fields appear most in filters and ensure scalar indexes cover them all.

Milvus's JSON field filtering is the most valuable capability for teams with schema-heterogeneous data. At billion-vector scale with multiple index types, partition keys, and scalar indexes all properly configured, Milvus handles filtered search workloads that would overwhelm alternatives. The operational requirement is real: getting all of these configuration decisions right requires engineering investment and ongoing tuning. Milvus rewards teams with dedicated infrastructure engineering capacity more than any other database in this comparison.

Open Source · Rust · Apache 2.0

Qdrant

One-Stage Payload Filtering

Filter System

One-stage in-traversal filtering

Payload index (all types)

Must / Should / Must-Not

Geo radius / polygon

Nested payload conditions

01One-stage payload filtering is Qdrant's most important technical differentiator. Standard post-filtering in ANN databases works in two steps: run HNSW to get approximate top-k candidates, then apply the filter to those candidates. When a filter is highly selective — only 0.1% of vectors match — post-filtering must retrieve 1000x more ANN candidates to find k passing results, degrading recall and increasing latency. Qdrant integrates payload conditions into the HNSW traversal itself: filtered search maintains target recall even under aggressive filtering.
02Payload conditions use a must / should / must-not structure. Must conditions are AND-combined (all must match). Should conditions are OR-combined (at least one must match). Must-not conditions exclude matches. The same logical operators available in Elasticsearch queries are available here — teams migrating from Elasticsearch to Qdrant find the filter syntax structurally familiar even though the underlying search is ANN rather than inverted index.
03Payload indexes cover all Qdrant-supported field types: keyword (exact match), integer (range), float (range), datetime (range and comparison), boolean, UUID, and geo (radius and polygon). Each index type has a structure optimized for that type's access pattern. A datetime field with a range condition uses a B-tree index; a keyword field with set membership uses a hash index. The index structure is chosen automatically from the field type declaration.
04Geo filtering is native: radius conditions (within X kilometers of a point) and polygon conditions (inside a defined geographic area). Combined with payload filtering, a RAG system can retrieve the k most semantically similar documents that are also geographically relevant and match a category filter in a single Qdrant query. No separate geo-database, no post-processing step combining results from two systems.
05Nested payload conditions: filter on properties inside nested JSON objects within a payload. A payload storing { "author": { "organization": "Anthropic", "joined": 2022 } } is filterable on author.organization and author.joined independently. Nested filtering enables access control policies stored as structured JSON in the payload to be enforced directly in the filter condition without preprocessing them into flat metadata fields.

Qdrant's one-stage payload filtering changes the production architecture of filtered RAG. In systems using post-filtering databases, engineers build retrieval strategies around the filter degradation: over-retrieve and post-filter, or partition by common filter values to reduce the scan scope. With Qdrant, neither workaround is necessary. The retrieval system returns accurate results under any filter selectivity without architectural complexity on the application side. For multi-tenant RAG with per-user access control, this architectural simplification is substantial.

05

How do they scale and perform in production?

Benchmark numbers are always approximate and hardware-dependent. What matters in production is whether the database can serve your query volume at your latency budget under your specific filter conditions, and whether it can grow to your scale ceiling without an architectural migration. All benchmark figures in this section are directional, sourced from published independent tests as of July 2026. Always verify against your specific workload.

View

SaaS Only · Proprietary

Pinecone

Billions Managed, Bursty-Optimal

Scale Numbers

Billions of vectors (managed)

p50 ~5-10ms serverless (under load)

Cold start: 200-2000ms

DRN: sustained high QPS

Auto-scaling, no capacity planning

01At 10M vectors under sustained load, independent benchmarks report Pinecone serverless at approximately 5-10ms p50 and 20-50ms p95 latency. This is higher than Qdrant's self-hosted numbers at equivalent scale but competitive with managed alternatives. The key qualifier is "sustained load" — serverless latency is favorable when the system is warm. Cold start latency of 200-2000ms after idle periods is a separate performance characteristic that benchmarks run under continuous load do not capture.
02Serverless auto-scaling means there is no capacity planning step. Write a vector; the storage scales. Run a query; compute is provisioned. This is operationally simpler than any alternative in this comparison and is the reason Pinecone remains the default choice for teams that have not yet determined their steady-state query volume. The scaling ceiling is managed by Pinecone, not by the engineering team.
03Dedicated Read Nodes (GA 2026) address the sustained high-QPS pattern. For applications serving 10,000+ queries per second at predictable traffic, DRN provides consistent sub-20ms p95 latency with no cold start problem. Pricing is per-node-hour. At very high sustained QPS, DRN cost can exceed the per-query serverless cost — teams should model both pricing models against their traffic shape before committing.
04Pinecone has published Nexus for agentic workloads — knowledge retrieval for agent memory systems. The published design target for Nexus retrieval is sub-100ms including network overhead for agent context retrieval at production scale. This is the latency target for real-time agentic applications where an agent retrieves context before generating each response token.
05At 100M vectors, Pinecone's cost typically exceeds $700/month on the usage-based model. Independent migration analyses published in mid-2026 suggest $300-500/month as the common trigger point where teams evaluate migrating to self-hosted Qdrant or Weaviate. The common migration path is Pinecone for development and initial production, then self-hosted open-source when monthly costs exceed a team-specific threshold, typically between $300-700/month.

Pinecone's scale story is best summarized as: serverless to billions without infrastructure work, at a cost premium that is acceptable at small-to-medium scale and increasingly painful at large scale. The cold start problem is the most common production complaint. Teams that benchmark Pinecone under continuous load and then deploy with bursty traffic discover the cold start issue after launch — always test with traffic patterns that match production, including idle periods.

Open Source · Go · BSD-3

Weaviate

100M-500M+, 3-Node HA

Scale Numbers

100M-500M+ vectors (self/cloud)

p50 ~4-8ms at 1M vectors

p95 ~30-70ms at production scale

3-node cluster for HA

HFresh extends RAM ceiling

01At 1M vectors on standard hardware (64GB RAM, NVMe SSD), Weaviate typically benchmarks at 4-8ms p50 and 30-70ms p95 for unfiltered similarity search. These numbers are directional from community benchmarks on VPS infrastructure using 768-dimensional embeddings (typical for production sentence-transformer models). At 100M vectors, latency increases as the HNSW graph grows, partially offset by HFresh's disk-backed navigation.
02Recommended minimum production cluster: 3 nodes for high availability with replication factor 3. A documented production architecture for billion-scale vectors specifies 64GB RAM per node, NVMe SSDs for index storage, 10GbE networking for cluster communication, and a load balancer for query distribution. At this scale, HFresh is the recommended index type — the full in-memory HNSW graph would exceed available RAM on any reasonably priced node.
03HFresh unlocks the scale ceiling for teams on existing hardware. Before HFresh, a Weaviate collection approaching the RAM limit of the available nodes required either adding hardware or migrating to a distributed deployment. HFresh stores the HNSW graph on NVMe and uses RAM only for the upper navigation layers — a 500M-vector collection that previously required 512GB RAM can run on a node with 64GB RAM and sufficient NVMe storage.
04Weaviate Cloud (Serverless tier retired October 2025, replaced by Flex at $45/month minimum) targets teams who want the managed Weaviate experience without running the cluster. The Dedicated Cloud tier provides single-tenant isolated clusters with HIPAA compliance, SOC 2 Type 2 certification, and SLA guarantees. For regulated industries where Weaviate's hybrid search and schema capabilities are the right fit, Dedicated Cloud removes the self-hosting requirement.
05Multi-tenant scale: Weaviate's per-tenant HNSW shard model means memory consumption scales with the number of active tenants, not just total vector count. A deployment with 10,000 tenants each with 10,000 vectors requires as much infrastructure as a deployment with 10 tenants each with 10M vectors, because the HNSW overhead exists per shard. Teams with many small tenants should evaluate the per-tenant shard model against flat single-collection alternatives at their specific tenant count.

Weaviate's performance story is solid for the workloads it is designed for — hybrid search, multi-modal data, complex filtered queries — but it is not the fastest pure vector search option. In benchmarks focused purely on unfiltered approximate nearest neighbor search at maximum QPS, Qdrant and Milvus with GPU indexing edge ahead. Weaviate's latency is good enough for user-facing production RAG; it is not the right choice when raw query throughput is the primary evaluation criterion.

Open Source · Go + C++ · Apache 2.0

Milvus

10B+ Vectors, GPU 4x Throughput

Scale Numbers

10B+ vectors (self-hosted)

~6ms p50 with GPU (CAGRA)

GPU: ~4x query throughput

DiskANN: disk-resident at scale

Independent query/write scaling

01Milvus is the only open-source vector database in this comparison documented for 10 billion+ vector deployments in production. The disaggregated architecture enables query nodes to be scaled independently of data nodes when search latency degrades under load, and data nodes to be scaled when ingestion throughput is the bottleneck. At billion-vector scale, this independent scaling is the difference between targeted infrastructure investment and over-provisioning all tiers simultaneously.
02GPU-accelerated search with CAGRA achieves approximately 6ms p50 latency on 1536-dimensional OpenAI embeddings with GPU indexing enabled. At equivalent collection size, this is faster than Pinecone's managed serverless and comparable to Qdrant's optimized Rust performance. For applications that can deploy GPU-enabled nodes — recommendation systems, real-time search ranking, high-frequency trading knowledge retrieval — Milvus with GPU indexing is the highest absolute throughput option in this comparison.
03GPU indexing with CAGRA delivers approximately 4x query throughput over CPU HNSW at equivalent recall. For batch search workloads that process thousands of queries per second — recommendation engines running during user sessions, overnight knowledge base refresh pipelines — GPU throughput changes the capacity equation. One GPU-enabled query node may replace four CPU query nodes for the same throughput target.
04DiskANN makes billion-vector self-hosting economically viable. An in-memory HNSW index for 1B 1536-dimensional float32 vectors requires approximately 6TB of RAM at full precision. DiskANN stores the graph on SSD with a compressed in-memory representation, reducing the RAM requirement to hundreds of GB. For teams whose data volume has outgrown available RAM but whose budget has not grown to match cloud RAM pricing, DiskANN changes what is buildable.
05A production gotcha documented in the Milvus community: retrieving scalar fields alongside vector results triggers a secondary fetch from object storage, dropping QPS by approximately 45% when returning 12 or more fields in one query. The recommended production pattern is to return only vector IDs from Milvus, then retrieve the associated document content from a separate relational database or document store. This two-hop retrieval pattern is counterintuitive but necessary for maintaining QPS targets at scale.

Milvus is the right choice at a scale where no other open-source vector database operates comfortably. For everything under 100M vectors, the operational complexity of Milvus is unjustified. Between 100M and 1B vectors, Qdrant and Weaviate are competitive and far simpler to operate. Above 1B vectors, or when GPU indexing is an explicit requirement, Milvus is the only viable open-source option and Zilliz Cloud is the only managed option other than Pinecone.

Open Source · Rust · Apache 2.0

Qdrant

Often Fastest, Best Self-Hosted

Scale Numbers

100M-500M+ (strong self-host)

p50 ~2-4ms at 1M vectors

p95 ~15-40ms at production scale

TurboQuant: 8x compression

Multi-AZ Cloud (2026)

01At 1M vectors, independent benchmarks consistently place Qdrant at 2-4ms p50 and 15-40ms p95 latency on standard VPS hardware for unfiltered ANN search — the fastest or among the fastest in comparisons across this group. The Rust runtime and contiguous memory layout produce these numbers structurally, not through benchmark-specific optimization. On the same hardware under the same query load, Qdrant's memory efficiency means more of the hardware's available resources go to serving queries rather than to runtime overhead.
02At 50M vectors on a single node, a VectorDBBench-based test reported Qdrant at 41 QPS at 99% recall — lower than some pgvector benchmark results in that specific test configuration. The important context: that test ran with specific hardware and index parameters that may not match production deployments. Independent real-world testing at similar scale with Qdrant's quantization enabled and TurboQuant active typically produces significantly higher QPS. Always run benchmarks with the full feature set that production will use.
03TurboQuant (v1.18, 2026) achieves 8x vector compression with better recall preservation than prior Qdrant quantization at equivalent compression ratios. At 100M 1536-dimensional float32 vectors, full-precision storage requires approximately 600GB of RAM. TurboQuant reduces this to approximately 75GB — within the range of a single high-memory server for many production workloads that previously required a distributed deployment.
04Qdrant Cloud added Multi-AZ replication and GPU indexing in 2026. Multi-AZ replication provides automatic failover across availability zones without application changes. The cloud pricing starts at $0.014/hr per node with no per-query fees — at 1M vectors under continuous query load, this is approximately $65-80/month, the lowest managed cost in this comparison. At 100M vectors, self-hosted on a $96/month DigitalOcean dedicated server is a frequently cited cost optimization relative to any managed option.
05Qdrant's filtering performance at scale is the most practically significant advantage over alternatives. In filtered search benchmarks at 10M vectors with filters selecting 1% of the collection, Qdrant maintains target recall within the unfiltered latency envelope. Alternatives using post-filtering see recall degrade to 70-80% or latency increase 3-5x to maintain target recall. For production RAG systems where every query has access control filters or tenant isolation conditions, this performance characteristic determines whether the system meets its SLA.

Qdrant is the strongest self-hosted choice for the 1M to 500M vector range in 2026. The Rust runtime, TurboQuant compression, one-stage payload filtering, and single-binary deployment combine into a production story that is hard to match at comparable cost. For teams where infrastructure simplicity and filtering performance are both priorities — the most common requirements in enterprise RAG deployments — Qdrant is frequently the conclusion reached after benchmarking all four options.

06

What does it cost and how do you deploy it?

The right database at the wrong cost is still the wrong database. Pricing models differ not just in amounts but in structure: per-query vs per-node vs per-storage changes which workloads are affordable and which create surprise bills. Deployment model determines who owns the operational burden and what compliance guarantees are available. All pricing figures are approximate estimates as of July 2026 and should be verified against current vendor pricing before any purchasing decision.

View

SaaS Only · Proprietary

Pinecone

Usage-Based, No Self-Host

Pricing Model

Builder: $20/mo

Standard: usage-based

~$70-400+/mo at 10M vectors

Storage: ~$0.33/GB/mo

No self-hosting option

01Builder tier introduced at $20/month (May 2026). Standard tier is usage-based: Read Units (RU) per query, Write Units (WU) per upsert, and storage per GB per month. Published storage pricing is approximately $0.33/GB/month. At 10M vectors with 1536-dimensional float32 embeddings (approximately 60GB), storage alone exceeds $19/month before any query or write cost. Total monthly bills at 10M vectors with moderate query volume typically fall in the $70-400 range depending on QPS.
02Read Unit pricing rewards filter efficiency. A query that returns results from a small, well-filtered namespace consumes fewer RUs than a query scanning the full index. The n8n Filter-then-Fetch pattern — filtering metadata in a cheap system before executing the vector query — reduces Pinecone RU consumption by 40-72% per published optimization guides. Teams experiencing high Pinecone bills before considering migration should evaluate filter optimization first.
03At 100M vectors under production query load, Pinecone monthly costs commonly reach $700-2000+. This cost level is the most frequently cited trigger for migration to self-hosted Qdrant or Weaviate in community discussions and published case studies. Independent analyses from 2026 suggest self-hosting at 50-100M vectors on cloud infrastructure costs roughly $100-400/month for open-source alternatives — a 3-10x cost reduction.
04BYOC (Bring Your Own Cloud) changes the cost model for large enterprises. The data plane runs in the customer's own AWS, GCP, or Azure account. The customer pays their cloud provider for the compute and storage directly; Pinecone charges a separate licensing fee. For enterprises already in a major cloud provider's committed spend program (EDP, CUD, Reserved Instances), BYOC allows vector storage costs to count toward existing cloud commitments.
05No self-hosting option exists and this is a deliberate product decision, not a gap. Pinecone is a SaaS product. Teams with data sovereignty requirements that cannot use cloud-hosted infrastructure (air-gapped environments, specific data residency regulations, government facilities) cannot use Pinecone in any tier including BYOC, which still requires a public cloud account. For those teams, the choice is between the three open-source alternatives.

Pinecone's pricing is the least predictable of the four at scale because it scales with query volume rather than infrastructure. A production system with variable traffic — marketing campaigns, seasonal demand, viral content — can see Pinecone bills spike 5-10x without any data volume change. Teams moving from prototype to production should model their query volume distribution (not just average QPS) against Pinecone's RU pricing before committing. The infrastructure-free development experience does not predict the infrastructure-variable production cost.

Open Source · Go · BSD-3

Weaviate

Flex $45/mo · Self-Host Free

Pricing Model

Self-hosted: free (infra only)

Flex: $45/mo minimum

Dedicated Cloud: custom

~$100-300+/mo managed at 10M

HIPAA / SOC 2 on Dedicated

01Self-hosting is free under the BSD-3 license. The only cost is the infrastructure: EC2, GKE, AKS, or on-premises servers. A 3-node Weaviate cluster on mid-range cloud instances serving a 50M-vector collection typically costs $150-400/month in cloud infrastructure. This is significantly cheaper than Pinecone at equivalent scale, at the cost of owning the cluster management, upgrades, monitoring, and failure recovery.
02Weaviate Cloud restructured pricing in October 2025. The old Serverless tier at $25/month was retired. The new Flex tier starts at $45/month (shared cloud infrastructure, 99.5% SLA, pay-as-you-go consumption). Teams on the old $25/month tier saw their minimum bill increase without receiving dedicated infrastructure. The pricing change was a point of community frustration documented in GitHub issues and the Weaviate Discord in late 2025.
03Dedicated Cloud provides single-tenant isolated clusters with HIPAA compliance, SOC 2 Type 2 certification, VPC peering, private endpoints, and SLA guarantees above the Flex tier. Pricing is custom based on cluster size and geographic region. For regulated industries — healthcare teams building clinical RAG systems, financial services teams building regulatory compliance search — Dedicated Cloud is the deployment tier that meets compliance requirements.
04Managed cloud at 10M vectors: estimated $100-300/month on Weaviate Flex depending on query volume and collection configuration. Self-hosted on equivalent infrastructure: approximately $80-200/month for the underlying compute, zero Weaviate license cost. The operational overhead of managing the cluster is the tradeoff for the cost saving. For teams with existing Kubernetes infrastructure and DevOps capacity, self-hosting is the clear cost-optimal choice.
05Multi-tenant cloud deployment: Weaviate's per-tenant HNSW shard model means cloud costs for multi-tenant applications scale with active tenant count, not just vector count. A deployment with 10,000 tenants each with 10,000 vectors incurs higher infrastructure cost than the raw vector count suggests. Teams evaluating Weaviate for SaaS applications with many small tenants should benchmark the per-tenant shard overhead against the vector count overhead of a flat single-collection deployment with tenant ID filtering.

Weaviate's pricing is attractive for mid-scale deployments that can absorb the operational cost of self-hosting. The open-source license and mature Docker/Kubernetes deployment story make self-hosting accessible to teams with basic infrastructure competence. The Dedicated Cloud tier addresses compliance requirements that self-hosting cannot satisfy without significant investment in security certifications. The October 2025 pricing restructure was the most significant Weaviate community friction point of the year and is worth understanding before planning budget around the managed offering.

Open Source · Go + C++ · Apache 2.0

Milvus

Self-Host Free · Zilliz Managed

Pricing Model

Self-hosted: free (K8s required)

Zilliz Cloud: $100-600+/mo

Storage: ~$0.04/GB (Jan 2026)

GPU cluster support

Kubernetes required at scale

01Milvus is Apache 2.0 licensed — free to use, modify, and distribute without commercial restrictions. Self-hosting is free beyond infrastructure costs. At billion-vector scale, the infrastructure cost for a self-hosted Milvus cluster running on cloud instances is significant — multiple node types (proxy, query, data, index), etcd, and object storage — but typically lower than any managed vector database option at comparable scale. The operational cost is engineer time, not licensing.
02Kubernetes is required for production Milvus deployments (Milvus Distributed). Helm charts and Kubernetes Operator are the supported deployment methods. Milvus Standalone (single-node, Docker) works for development and testing at small scale but does not support the high-availability and horizontal scaling features that justify choosing Milvus over simpler alternatives. Teams without Kubernetes infrastructure cannot deploy production Milvus without first building it.
03Zilliz Cloud (managed Milvus) dropped storage pricing by 87% in January 2026: from $0.30/GB/month to approximately $0.04/GB/month. At 100M 1536-dimensional float32 vectors (approximately 600GB uncompressed), this reduces Zilliz storage cost from $180/month to approximately $24/month — a significant reduction that closed much of the cost gap between Zilliz and self-hosted alternatives at moderate scale. Total Zilliz Cloud cost at 10M vectors is estimated at $100-600/month depending on query throughput tier.
04Zilliz Cloud claims 10x faster performance than self-hosted Milvus for equivalent workloads. This reflects infrastructure optimization and co-located object storage that self-hosted deployments cannot match without equivalent investment. The 10x number is a Zilliz-published claim rather than an independent benchmark. What is credible: Zilliz removes the most expensive performance bottleneck in self-hosted Milvus (object storage latency) and adds SLA-backed reliability that self-hosting cannot provide without substantial operational investment.
05At 100M vectors on Zilliz Cloud, costs range from approximately $200-1000/month depending on QPS tier, replication factor, and geographic region. Self-hosted Milvus Distributed on equivalent cloud infrastructure (EC2 or GKE with multiple node types and object storage) costs approximately $400-800/month in cloud infrastructure with significant engineer time overhead. The cost gap between managed and self-hosted narrows significantly at Milvus scale because the infrastructure complexity of self-hosting Milvus is genuinely high.

Milvus's cost story requires honest accounting of engineering time. The infrastructure cost of self-hosted Milvus at scale is lower than Pinecone or Zilliz Cloud. The total cost of ownership — including the engineer time to deploy, operate, tune, and maintain a production Kubernetes Milvus cluster — is higher than community discussions typically acknowledge. Teams should model engineering hours at their internal rate against the Zilliz Cloud premium before concluding that self-hosting saves money. For most teams under 500M vectors, it does not.

Open Source · Rust · Apache 2.0

Qdrant

$0.014/hr/node · No Per-Query Fee

Pricing Model

Self-hosted: free (Docker)

Cloud: $0.014/hr per node

~$65-80/mo at 1M vectors

No per-query fees

Multi-AZ, GPU indexing (2026)

01Self-hosting Qdrant starts with a single Docker command. No Kubernetes, no etcd, no object storage, no message bus. A production-ready Qdrant instance is a single binary on a single server. For teams at 1M to 100M vectors without a Kubernetes infrastructure already in place, Qdrant's self-hosting story is more accessible than any alternative in this comparison. Clustering is available for scale-out when the single-node ceiling is reached — it does not require Kubernetes, though it supports it.
02Qdrant Cloud pricing is node-based: $0.014/hour per node, with no per-query fees. At one node running continuously, this is approximately $10/month — the lowest entry point in the managed tier. At 1M vectors, a standard Qdrant Cloud configuration costs approximately $65-80/month including storage and compute. At 10M vectors, approximately $100-250/month depending on the node size required. The absence of per-query fees means traffic spikes do not produce surprise bills.
03Node-based pricing with no per-query fees is structurally favorable for high-QPS production applications. A Pinecone deployment at 10,000 QPS accumulates RU costs proportionally to every query. A Qdrant Cloud deployment at 10,000 QPS pays only for the nodes needed to serve that throughput. For sustained high-QPS traffic with predictable query volume, Qdrant's per-node model is significantly cheaper. For bursty low-volume traffic where Pinecone serverless scales to zero, Qdrant requires minimum node cost even at zero queries.
04Self-hosted cost optimization: a community migration case study published in 2026 documents moving from Pinecone (billing over $300/month) to Qdrant self-hosted on DigitalOcean ($96/month for a dedicated server). TurboQuant's 8x compression reduced the required server size. The migration reduced vector database infrastructure cost by approximately 70% with comparable query latency. This pattern — Pinecone for development, Qdrant self-hosted at scale threshold — appears in multiple community discussions as a common production architecture evolution.
05Qdrant Cloud added Multi-AZ replication and audit logging in 2026 for enterprise deployments. GPU indexing is now available on cloud nodes, matching Milvus's GPU capability at smaller scale. SOC 2 compliance and data residency in European and North American regions are available on enterprise tiers. For regulated-industry teams who need managed deployment with compliance certifications but do not need Milvus-scale capacity, Qdrant Cloud's enterprise tier is increasingly a production-ready option.

Qdrant is the most cost-effective vector database for the 1M to 500M vector range in managed and self-hosted configurations. The combination of no per-query fees, TurboQuant compression reducing hardware requirements, and single-binary self-hosting producing the lowest operational overhead makes the total cost of ownership lower than alternatives across most workloads in this range. The one scenario where Qdrant's cost advantage narrows: extremely low-volume bursty traffic where Pinecone's scale-to-zero serverless pricing beats Qdrant's minimum node cost.

M

Methodology

What counts as a fact, what counts as inference, and how to use this research responsibly.

📄

Official Documentation

Vendor docs, GitHub READMEs, official release notes, and pricing pages. Highest confidence tier. Verified against source URLs at research time, July 2026.

📊

Published Benchmarks

VectorDBBench data, independent community benchmark articles, and performance reports from lushbinary.com, elest.io, and firecrawl.dev. Directional only. Always re-run against your specific workload.

💰

Pricing Estimates

Derived from published pricing pages and community cost analyses. Approximate. Verify current pricing directly with vendors before any purchasing decision. Pricing changes frequently.

💭

Author Synthesis

Comparative assessments and architectural interpretations drawn from the above sources. Marked with the insight label. These are reasoned conclusions, not documented facts. Disagree with the reasoning, not the source.

What this study claims and does not claim

Every numbered point is sourced from official documentation, published benchmarks, or verified community analyses. Benchmark figures are directional and hardware-dependent. The same database on different hardware, with different embedding dimensions, different filter conditions, and different query concurrency will produce different numbers. Use the figures here to understand relative performance characteristics, not to predict your specific production performance.

The insight sections at the bottom of each block are the author's interpretation. They represent synthesis and reasoned conclusions from the primary sources. A reader who disagrees should disagree with the reasoning, not treat the insight as a documented claim.

What is excluded

pgvector is not covered as a primary database in this volume despite being an important option for teams already on PostgreSQL. The decision was to focus on purpose-built vector databases. pgvector is a strong choice for under 10-50M vectors with existing Postgres infrastructure and will be addressed in depth in a future volume on RAG architectures. No leaked materials or unverified internal documents were used. Benchmark comparisons from vendor marketing materials were excluded — only independent or community benchmarks were referenced.

Research process

Researched in July 2026. Primary sources were official documentation for Pinecone, Weaviate, Milvus, and Qdrant as of the research date. Secondary sources included MarkTechPost's May 2026 comparison, Lushbinary's July 2026 production benchmark guide, elest.io's March 2026 comparison, RankSquire's May 2026 vector database news, and firecrawl.dev's May 2026 selection guide. Release notes for Qdrant 1.17, 1.18, Weaviate 1.38, and Milvus 2.6 were consulted directly. Pricing figures reflect vendor pricing pages as of July 2026.

Last Updated: July 20, 2026

Swarnim
Tiwari

AI Systems Researcher

I got into this because I was reading AI news every day and felt like I was learning nothing. Every article says AI is changing everything. Nobody actually explains how any of it works.

So I started reading the real stuff. Documentation, system cards, engineering blogs, SEC filings. Then built this series to make sense of what I found.

Each volume takes one topic in AI infrastructure and goes deep on it. By the time you finish reading, you should understand how something actually works. Not what a company says it does. What the architecture shows.

I am a student based in India, building and researching in public. If you spot something wrong or outdated, reach out.

LinkedIn GitHub

AI Systems Studies — Publication Series

Vol. 01Production AI Architecture — OpenAI, Anthropic, Palantir, NVIDIAPublished

Vol. 02AI Agent Frameworks — OpenAI SDK, LangGraph, CrewAI, MastraPublished

Vol. 03Vector Databases — Pinecone, Weaviate, Milvus, QdrantThis Study

Vol. 04AI Observability — LangSmith, Langfuse, Helicone, W&BPlanned

Vol. 05Inference Infrastructure — vLLM, SGLang, TensorRT-LLM, TGIPlanned

Vol. 06Context EngineeringPlanned

Vol. 07Memory SystemsPlanned

Vol. 08RAG ArchitecturesPlanned