Qdrant Beats Elastic’s DiskBBQ at 2x Throughput, Half the Latency, and 1/3 the Compute

2026-07-08 · Source: Qdrant Blog on Qdrant - Vector Search Engine · Field: Technology & Digital — Artificial Intelligence & Machine Learning, Data Science & Analytics, Cloud Computing & IT Infrastructure · Depth: Intermediate, medium

Summary

Qdrant recently published a benchmark refuting Elastic's claims that its proprietary DiskBBQ index offers up to 7x higher throughput than Qdrant for disk-based vector search. Qdrant's re-evaluation, using the same wiki_dpr_e5 dataset of 21 million 768-dimensional embeddings, demonstrated significantly superior performance. By correctly configuring Qdrant with TurboQuant 4-bit, two-stage retrieval, and async disk scoring, Qdrant achieved 2.1x higher throughput and 51% lower latency at a recall@100 of approximately 0.96. This was accomplished on three m6g.large instances (2 vCPU / 8 GiB RAM each), representing roughly one-third of the per-node CPU and RAM used by Elastic's n4-standard-8 nodes (7 vCPU / 26 GB RAM each). Elastic's original benchmark, which reported 32.4 QPS at 122.6 ms latency for DiskBBQ, was surpassed by Qdrant's 67.2 QPS at 59.5 ms latency on smaller hardware.

Key takeaway

For MLOps Engineers evaluating vector database solutions for large-scale, disk-based search, you should critically review benchmark methodologies and ensure proper configuration. Qdrant's demonstrated performance, achieving 2x throughput and half the latency on one-third the compute compared to Elastic's DiskBBQ, suggests significant cost savings and efficiency gains. Consider Qdrant's two-stage retrieval with TurboQuant 4-bit and async disk scoring to optimize your resource footprint and performance for similar workloads.

Key insights

Proper configuration of vector databases is crucial for optimal disk-based search performance and resource efficiency.

Principles

• Benchmarking requires accurate configuration.
• Quantization reduces memory footprint.
• Two-stage retrieval improves accuracy.

Method

Implement two-stage retrieval by prefetching quantized vectors, then rescoring a bounded set with full-precision vectors from disk.

In practice

• Enable async_scorer for parallel disk reads.
• Use TurboQuant 4-bit for disk-based workloads.
• Configure vectors.on_disk=true for large datasets.

Topics

• Vector Databases
• Qdrant
• Elasticsearch DiskBBQ
• Vector Search Benchmarking
• TurboQuant 4-bit
• Two-stage Retrieval

Code references

• qdrant-labs/wiki-dpr-disk-rescore-benchmark

Best for: CTO, VP of Engineering/Data, Director of AI/ML, Machine Learning Engineer, AI Engineer, MLOps Engineer

Related on AIssential

• Qdrant 1.18 - TurboQuant — TurboQuant offers superior vector compression and recall, while Qdrant 1.18 enhances monitoring and schema flexibility.
• Processing 1 TB with DuckDB in less than 30 seconds — DuckDB can efficiently process terabyte-scale datasets, challenging its "small data" perception.
• How Sapu Indexed 28 Million PubMed Abstracts to Accelerate Cancer Research with Qdrant — Scaling biomedical research with AI requires robust, compliant vector search infrastructure like Qdrant Cloud.
• How to Use Semantic Caching with Qdrant to Optimize Token Costs in Customer Support — Semantic caching with Qdrant reuses LLM responses for semantically similar queries, drastically cutting costs and latency.
• Vector Database Shootout: Postgres+pgvector vs. Qdrant vs. Pinecone — Vector database selection for RAG now prioritizes scalability and cost-efficiency over basic functionality.
• How HubSpot Scaled Semantic Search to 20 Billion Vectors — Scaling vector search demands robust operational automation beyond just the database.

See Counsel's argued verdicts on the open AI decisions leaders are weighing →

Open in AIssential →

Editorial summary, takeaway, and curation by AIssential. Original article published by Qdrant Blog on Qdrant - Vector Search Engine.