Vector search benchmark: Elasticsearch matches Qdrant - Elasticsearch Labs
Start free trial
Blog
The disk that never woke up: what actually decided our Qdrant vector search benchmark rematch<br>On the same hardware, Elasticsearch and Qdrant land in the same range at 56 QPS. The io_uring disk scorer and memory claims turned out to be the two things that mattered least.<br>Vector Database<br>JF<br>By: Jim FerencziJuly 13, 2026
Try out vector search for yourself using this self-paced hands-on learning for Search AI. You can start a free cloud trial or try Elastic on your local machine now.
Vector search vendors like a good benchmark, and lately Elasticsearch and Qdrant have been trading them. Earlier this year we published one comparing Elasticsearch's bbq_disk against Qdrant on a disk-rescore workload, where full-precision vectors live on disk and get read back to rescore the top candidates. Qdrant replied with better numbers on their side and a set of explanations for why: an io_uring-based async disk scorer, and remarks about Elasticsearch needing more memory.<br>We didn't want to fire back with another round of numbers. Reproducing a benchmark is the easy part; understanding why it produces the numbers it does is the useful part, and it is the part both original posts skipped. So we stood up Qdrant's exact setup on our own cluster, loaded the same 21 million vectors, reproduced their result, and then traced every number back to its cause.<br>Here is what we found. The result comes down to a few setup choices: how many segments you build, whether the data is warm in memory, how you return the result ids, and which hardware you run on. Control those, and it cuts both ways: matched to Qdrant's setup the two engines are on par on query speed, and with fast default ingestion Elasticsearch is faster at search and faster to index. The big multipliers in both posts, our 7x and their reply, are artifacts of those choices, not a verdict on either engine. The two reasons Qdrant leaned on hardest, an io_uring disk scorer and Elasticsearch's memory use, turn out to be the two that mattered least: the disk is never read during the run, and the memory gap is a difference in labels, not in bytes.<br>We hold our own original post to the same standard. Both sides changed several things at once and reported the result rather than the reason. One rule for the rest of this post: every claim gets a number and a mechanism, or it doesn't ship.<br>Vector search benchmark setup: hardware, config and query set<br>Here is exactly what each side ran.
Elastic (original post)Qdrant (response)This post (apples-to-apples)Nodes3 × n4-standard-8 (7 vCPU / 26 GB), GCP3 × m6g.large (2 vCPU / 8 GB), AWS3 × m6g.large (2 vCPU / 8 GB)Elasticsearchbbq_disk 2-bit, replicas: 1(cited original)bbq_disk 2-bit, vectordb_document, bfloat16, replicas: 0Qdrant2-bit, async scorer off, RF=2TurboQuant 4-bit, async scorer on, RF=1TurboQuant 4-bit, async scorer on, RF=1Copies per shard2 = 2 (matched)11 = 1 (matched)Query set10k fixed, recall@10010k fixed, recall@10010k fixed, recall@100<br>Three things are worth pinning down, because all three have been used as talking points.<br>Replica count was matched in both rounds: An Elasticsearch index with replicas: 1 keeps two copies of each shard, which is exactly what Qdrant's RF=2 does. In this round, both sides ran a single copy. It was never a thumb on the scale in either direction.<br>We changed a few things on our side on purpose, and we will own them: vectordb_document index mode, float32 to bfloat16 for stored full-precision vectors (3,072 down to 1,536 bytes each), and a merge policy tuned for vector data. Those choices matter later, so we are flagging them up front rather than burying them.<br>Memory is compared like for like. Qdrant's post sets Elasticsearch's JVM heap allocation against Qdrant's total memory use, but those are different accounting categories, since heap size is not total memory consumption. On these 8 GB nodes we give the JVM heap 2 GB, 25% of node RAM, deliberately: that follows Elastic's Vector Search Optimized profile, which leaves the other 75% for the OS page cache where the vectors actually live, rather than the general 50%-heap upper bound. The honest comparison is resident index plus runtime plus active page cache, and on an 8 GB node both engines live inside the same envelope.<br>Look at the middle column, though. Between our original run and their response, Qdrant changed almost everything at once: new hardware, 4-bit quantization instead of 2-bit, the async scorer on, a different replication factor. Then it credited the win to one of those changes. Drawing meaningful conclusions from many simultaneous changes is hard, and pinning down which change actually moved the number is the whole job of the sections that follow.<br>What does disk rescore cost in a vector search benchmark?<br>In this benchmark, the answer is almost nothing, because the disk is never read. Two back-of-the-envelope budgets show why, and the live...