8DB delivered 8,551 vector searches per second at 99.04% recall in our local test of real text embeddings. Qdrant delivered 4,682 at 99.53%, using the fastest tested setting from each engine that cleared a 99% recall requirement. That is 1.83 times the throughput in this workload.
For teams choosing a database, the useful question is whether similarity search can meet the application's needs alongside the rest of its data. 8DB is an omnimodal database: vector retrieval sits alongside native graph, hypergraph, time-series, spatial and other capabilities. Competitive vector performance strengthens that broader proposition.
The result also has clear boundaries. This was warmed, unfiltered retrieval on a shared workstation, through different service transports. We did not match durability or governance guarantees. Qdrant built its index much faster and led at the strictest tested recall requirement. The comparison gives us a practical operating range to discuss with users, rather than an overall database ranking.
Choose the quality requirement before comparing speed
Vector search finds nearby points in an embedding space. Approximate indexes save work by examining only part of that space. Recall@10 measures how many of the exact ten nearest neighbors the returned answers recover, averaged across queries. It does not measure whether an AI-generated answer is useful or correct.
We indexed 99,488 normalized, 768-dimensional Wikipedia passage embeddings, used 512 distinct passage queries and returned ten neighbors per search. Eight clients queried each service. Independent exhaustive calculations supplied the reference neighbors and checked returned distances. The dataset mirror supplies real embeddings, although passage-to-passage queries are not a representative production question stream.
The table selects the fastest tested setting that satisfied each minimum recall requirement. Actual recall is shown because meeting the same floor does not mean returning equally accurate answers.
| Minimum recall | 8DB searches/sec | 8DB actual recall | Qdrant searches/sec | Qdrant actual recall |
|---|---|---|---|---|
| 99% | 8,551 | 99.043% | 4,682 | 99.531% |
| 99.5% | 5,516 | 99.766% | 4,682 | 99.531% |
| 99.9% | 3,383 | 99.961% | 2,228 | 99.922% |
| 99.98% | 1,100 | 100.000% observed | 1,445 | 99.980% |
Same local corpus, eight clients and a 2 GiB server cap. Five timing passes reused one graph per engine. Shared host, different transports and unmatched persistence/governance; bars show tested configurations, not interpolated optima.
At the 99% floor, 8DB's p99 response time was 1.426 milliseconds, versus 2.559 milliseconds for Qdrant. At the 99.98% floor, Qdrant's 9.051 milliseconds beat 8DB's 10.971 milliseconds. The best choice changes with the quality requirement.
There are only 5,120 reference neighbor slots in these 512 queries. Qdrant's strictest point misses one slot; 8DB's observed 100% point misses none. Repeating queries helps characterize timing, but does not turn this into a larger quality sample. A denser search-setting sweep could also change which tested point wins at a particular floor.
We improved quality and speed together
The previous 8DB policy never reached 98% recall on this text-embedding corpus. Its maximum observed recall across the tested search settings was 96.602%.
At the fastest tested points meeting a 95% floor, the change was substantial:
| Local service configuration | Searches/sec | Recall@10 | p99 |
|---|---|---|---|
| Previous 8DB policy | 1,638 | 95.879% | 7.295 ms |
| Optimized 8DB policy | 8,551 | 99.043% | 1.426 ms |
| Qdrant, prepared gRPC client | 5,524 | 98.867% | 2.043 ms |
That is approximately 5.2× our previous throughput and 80% lower p99, while recovering more correct neighbors. These are tuned operating points, not an isolated comparison of one instruction or identical search settings.
We improved index connectivity and reduced unnecessary work during traversal and distance calculation. We also corrected batch handling so each query receives its own search and scores. Reusing one query's answers for another cannot count as a useful speedup.
The changes are merged and passed the required engineering checks. Operators can adjust live search effort and its minimum setting, while build profiles make the construction-versus-quality tradeoff explicit. Those controls support tuning; they do not automatically guarantee a chosen recall on unseen queries.
Loading is a separate decision
In the main text-embedding campaign, 8DB's index-ready time fell from 390 seconds to 166 seconds, with one construction thread. Qdrant reached fully indexed readiness in 18.3 seconds, using up to eight construction threads and a persisted index. Its earlier upload acknowledgment was a different milestone.
A subsequent bounded settings pass found an optional faster-build profile:
| Later 8DB calibration | Median build time | Recall at query beam 100 | Searches/sec at that beam |
|---|---|---|---|
| Existing build profile | 195.3 s | 99.766% | 5,542 |
| Optional faster-build profile | 97.8 s | 99.668% | 6,098 |
Both profiles were rebuilt twice. The fresh control is the appropriate comparison for this pass; shared-machine variation helps explain why it differs from the earlier 166-second observation. Qdrant was not rerun in this calibration. The faster build changes the graph and gives up some recall, so it remains an option rather than a new universal default.
For a stable corpus, construction is an occasional cost amortized over many searches. For frequent rebuilds, short-lived indexes or rapid onboarding, the readiness gap matters much more. Our best earlier search number and our fastest build profile describe different configurations.
Both engines served the tested query curves under a 512 MiB server cap after construction at 2 GiB, without observed server swap or out-of-memory failure. After Qdrant restarted its persisted index, its sampled memory maximum was about 418 MiB, close to 8DB's 399 MiB in the corresponding 2 GiB serving phases. This does not establish a lasting memory advantage or prove either engine can build under the smaller cap. Energy and physical storage wear were not measured.
Where this sits among the alternatives
The local Qdrant comparison is our strongest service-level reference in this campaign. A separate SIFT1M component test, on one million 128-dimensional vectors, provides another useful perspective:
| SIFT component, minimum 99% recall | Searches/sec | Actual recall | p99 |
|---|---|---|---|
| Prior 8DB M32 policy | 3,612 | 99.159% | 3.719 ms |
| Optimized 8DB | 7,404 | 99.725% | 1.583 ms |
| hnswlib | 13,348 | 99.545% | 1.016 ms |
8DB roughly doubled its throughput while improving recall, but the specialist library remained faster. Those historical controls were not freshly interleaved. This is an in-process comparison on a different corpus, not a ranking against the service numbers above. hnswlib is an index library rather than a complete database service.
Buyers also have several credible product choices:
- Qdrant supports hybrid and multistage queries, beyond the unfiltered dense retrieval tested here.
- Pinecone offers managed vector retrieval and broader agent-oriented products. We did not benchmark its production service and make no speed claim against it.
- Weaviate and Milvus provide specialist retrieval platforms. Weaviate publishes ANN benchmarks; Milvus documents multi-vector hybrid search. Their separate campaigns cannot be inserted into this local ranking.
- PostgreSQL with pgvector keeps vectors alongside relational data, joins and transactional capabilities. Bringing more of an application into one database is already a meaningful alternative, not a benefit exclusive to 8DB.
What comes after the nearest match?
Consider a maintenance investigation. A similar failure report is the beginning. The next questions concern the affected component, its supplier, the installations using it, the relevant contracts and what sensor readings showed before the failure.
8DB's native graphs and hypergraphs can represent those relationships, including facts involving several participants. Its time-series capabilities can retain richer evidence than a timestamp attached to a vector. Lattice and braid operations offer additional ways to work with ordering, conflicts and relationships over time.
The architectural opportunity is to keep more of this work close to the data, reducing the representations and handoffs an application must maintain. Faster vector retrieval improves one stage. Whether the complete process is cheaper, faster or easier to protect depends on the actual integration and guarantees. This campaign did not establish authority-aware vector retrieval or one protected, consistent snapshot across that whole workflow.
Vector search is one part of our broader performance work. Our articles on graph lookups, time-series ingestion, key-value operations and analytics examine other modalities separately. Their peak results should not be added together as simultaneous application performance.
Bring us the query your application actually needs to answer, together with its quality requirement, data size and deployment constraints. Discuss a workload evaluation. The useful comparison is the cost and reliability of completing that job, with vector speed as one of the inputs.
Measurement notes and evidence
The September 18, 2026 service campaign ran under WSL2 on an AMD Ryzen 9 9950X3D workstation; Linux exposed 16 logical CPUs. Each server had a 2 GiB memory cap for the principal comparison. Eight clients drove each service, but CPU affinity and server CPU quotas were not matched. Unrelated host work remained active, so timing is directional local evidence rather than an isolated-hardware result.
Qdrant was pinned to version 1.19.1. Its comparison client used prepared gRPC requests and decoded IDs/distances, avoiding extra SDK conversion work inside the timer. 8DB used its native TCP route. Qdrant had restarted the same persisted index before that control; lifecycle differences therefore accompany the transport differences. The measured 8DB index was derived and in memory. Neither this result nor in-memory batch publication certifies crash durability, filtered retrieval, revocation behavior or production application relevance.
The original historical article draft used a 4,707-searches/sec SIFT service result at 95.71% recall on an AWS 8-vCPU host. It remains part of our history, but is not a directly comparable baseline for this smaller, higher-dimensional text corpus. We retain the original evidence rather than manufacture a continuous speedup across different machines and workloads.
The public measurement supplement contains the reported operating points, settings, dataset and binary fingerprints, comparison boundaries and chart inputs. Private raw trials, resource samples, source snapshots and reproduction scripts are retained separately. These are custom benchmark harness results, not an official VectorDBBench submission.
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work