Qdrant vs Weaviate: Pricing & Performance 2026

Qdrant's Rust-Based HNSW: Concrete Performance Numbers

Qdrant's query engine is written entirely in Rust with no garbage collection pauses and a memory-mapped segment architecture that keeps hot data in RAM while spilling cold data to NVMe with minimal latency impact. Published benchmarks from the ann-benchmarks suite (June 2025) show Qdrant achieving 8,400 queries per second at 99% recall on the 10M-vector deep-1B subset using a 32-core, 64GB RAM node — with P99 latency of 7.2ms at ef=128. Weaviate on the same hardware achieves approximately 4,100 QPS at the same recall target, with P99 latency around 13.8ms.

The gap narrows significantly at lower QPS. If your application never exceeds 200 concurrent queries per second, both databases have more than enough headroom on modest hardware, and the performance difference is imperceptible to end users. The Rust advantage becomes decisive only at sustained high-throughput workloads — recommendation systems, real-time document ranking, or anything generating tens of millions of queries per day.

gRPC vs HTTP: The Ingestion Bottleneck

Qdrant exposes both a REST API (port 6333) and a gRPC API (port 6334). For high-volume ingestion pipelines — loading 50M vectors from a batch job, for example — gRPC's binary protocol and HTTP/2 multiplexing reduce ingestion time by 30–50% compared to REST/JSON, according to Qdrant's own benchmarks. A 10M vector load that takes 4.5 hours over REST completes in under 3 hours over gRPC on the same hardware. Weaviate has no gRPC support as of June 2026; all communication is HTTP/1.1 or HTTP/2 REST and GraphQL. For teams with large initial dataset loads, this is a meaningful operational difference.

Weaviate's Module Ecosystem: Server-Side Intelligence

Weaviate's plugin architecture embeds embedding and inference directly into the database server. Configuring text2vec-openai at the class level means every object you insert is automatically vectorized server-side — you send raw text, Weaviate calls OpenAI's embedding API on your behalf, and stores the resulting vector. This eliminates an entire step from your ingestion pipeline. You never write embeddings = openai.embed(text) in your application code; Weaviate handles it. Changing your embedding model later requires only a schema update and a re-indexing trigger, not changes to all ingestion code paths.

The reranker-cohere and reranker-transformers modules extend this pattern to retrieval. A GraphQL query can specify rerank as a pipeline stage, and Weaviate sends retrieved candidates to a cross-encoder for score refinement entirely server-side. With Qdrant, re-ranking requires retrieving candidates in your application, calling the cross-encoder model yourself, and re-sorting the results before presenting them to the user — more control, but more code to maintain.

Payload Filtering: Different Implementations, Similar Results

Both databases support pre-filtering (apply metadata filter before ANN search) and post-filtering (apply filter to ANN results). Qdrant's payload filter uses a typed DSL defined in the API schema: {"must": [{"key": "category", "match": {"value": "finance"}}]}. This is validated at the client-SDK level, so type errors are caught before the network call. Weaviate's GraphQL where filter is similarly typed and validated, but expressed in GraphQL syntax: where: {path: ["category"], operator: Equal, valueText: "finance"}. Both approaches work well; the preference is largely a matter of which query language your team is already comfortable with.

One noteworthy difference: Qdrant supports filtering on nested JSON payload keys, including arrays, with its nested filter condition. Weaviate supports filtering on properties of cross-referenced objects, which is a more relational model but requires explicitly defining cross-references in your schema. For documents with deeply nested metadata, Qdrant's flat-payload approach is more flexible without schema changes.

Memory Footprint: Where Qdrant Has a Structural Edge

Weaviate's object store keeps a copy of the original object properties in an embedded key-value store alongside the HNSW graph. This means Weaviate's memory footprint scales with both vector dimensions and the size of stored object properties. Qdrant's payload store is optimised separately from the vector index — you can configure which payload fields are indexed for filtering and which are stored cold, giving fine-grained control over RAM usage. At 10M vectors with 1536 dimensions and modest metadata (~500 bytes per object), Weaviate typically requires about 15% more RAM than Qdrant for the same dataset, based on community benchmarks from the Qdrant and Weaviate Discord servers.

At the 100M vector scale, this difference compounds: Qdrant's mmap-backed segments can handle datasets larger than available RAM by paging cold segments to NVMe, accepting a latency penalty only for cold queries. Weaviate does support lazy loading of segments in v1.24+, but Qdrant's segment management tooling is more mature for datasets that exceed memory limits.

Developer Experience: A Tale of Two Query Languages

The teams behind each database have made a clear bet on their query interface. Qdrant's REST API is JSON-first and imperative — you describe what you want precisely, with no abstraction layer between your intent and the wire format. Engineers who prefer explicit control and minimal magic tend to find Qdrant's API satisfying. Weaviate's GraphQL interface is declarative and composable — you describe a retrieval pipeline as a nested query structure, and the server executes each stage in order. Engineers building complex RAG pipelines with multiple retrieval stages tend to find Weaviate's approach more readable once the initial learning curve is behind them.

Both provide first-class Python and TypeScript/JavaScript SDKs. Qdrant additionally provides a Rust SDK (as expected) and Go client. Weaviate's Python client has excellent async support and a fluent query builder API that partially abstracts the GraphQL syntax for engineers who prefer method chaining over raw GraphQL strings.