krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-09-28 15:38:33 +02:00
Code Issues Packages Projects Releases Wiki Activity

spacing updates to the paragraphs

Browse Source
This commit is contained in:
Sabrina Aquino
2024-01-15 15:52:36 -03:00
parent 9b5dc27f0c
commit 021545c6c4
1 changed files with 15 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/blog/qdrant-updated-benchmarks-2024.md
+15 -5
View File
@@ -20,13 +20,17 @@ tags: # Change this, related by tags posts will be shown on the blog page
- performance
---
It's time for an update to Qdrant’s benchmarks. We've compared how Qdrant performs against the other vector search engines to give you a thorough performance analysis. Let's get into what's new and what remains the same in our approach.
It's time for an update to Qdrant's benchmarks!
We've compared how Qdrant performs against the other vector search engines to give you a thorough performance analysis. Let's get into what's new and what remains the same in our approach.
### What's Changed?
#### All engines have improved
Since the last time we ran our benchmarks, we received a bunch of suggestions on how to run other engines more efficiently, and we applied them. This has resulted in significant improvements across all engines. As a result, we have achieved an impressive improvement of nearly four times in certain cases. You can view the previous benchmark results [here](https://qdrant.tech/benchmarks/single-node-speed-benchmark-2022/).
Since the last time we ran our benchmarks, we received a bunch of suggestions on how to run other engines more efficiently, and we applied them.
This has resulted in significant improvements across all engines. As a result, we have achieved an impressive improvement of nearly four times in certain cases. You can view the previous benchmark results [here](https://qdrant.tech/benchmarks/single-node-speed-benchmark-2022/).
#### Introducing a New Dataset
@@ -35,7 +39,9 @@ To ensure our benchmark aligns with the requirements of serving RAG applications
![rps vs precision benchmark - up and to the right is better](/blog/qdrant-updated-benchmarks-2024/rps-bench.png)
#### Separation of Latency vs RPS Cases
Different applications have distinct requirements when it comes to performance. To address this, we have made a clear separation between latency and requests-per-second (RPS) cases. For example, a self-driving car's object recognition system aims to process requests as quickly as possible, while a web server focuses on serving multiple clients simultaneously. By simulating both scenarios and allowing configurations for 1 or 100 parallel readers, our benchmark provides a more accurate evaluation of search engine performance.
Different applications have distinct requirements when it comes to performance. To address this, we have made a clear separation between latency and requests-per-second (RPS) cases.
For example, a self-driving car's object recognition system aims to process requests as quickly as possible, while a web server focuses on serving multiple clients simultaneously. By simulating both scenarios and allowing configurations for 1 or 100 parallel readers, our benchmark provides a more accurate evaluation of search engine performance.
![mean-time vs precision benchmark - down and to the right is better](/blog/qdrant-updated-benchmarks-2024/latency-bench.png)
### What Hasn't Changed?
@@ -48,10 +54,14 @@ At Qdrant all code stays open-source. We ensure our benchmarks are accessible fo
Our benchmarks are strictly limited to open-source solutions, ensuring hardware parity and avoiding biases from external cloud components.
We deliberately don't include libraries or algorithm implementations in our comparisons because our focus is squarely on vector databases. Why? Because libraries like FAISS, while useful for experiments, don’t fully address the complexities of real-world production environments. They lack features like real-time updates, CRUD operations, high availability, scalability, and concurrent access – essentials in production scenarios. A vector search engine is more than an indexing algorithm.
We deliberately don't include libraries or algorithm implementations in our comparisons because our focus is squarely on vector databases.
Why?
Because libraries like FAISS, while useful for experiments, don’t fully address the complexities of real-world production environments. They lack features like real-time updates, CRUD operations, high availability, scalability, and concurrent access – essentials in production scenarios. A vector search engine is not only its indexing algorithm, but its overall performance in production.
We align our benchmarks with the [ann-benchmarks](https://github.com/erikbern/ann-benchmarks/#data-sets) project, so you can align your expectations for any practical reasons.
We use the same benchmark datasets as the [ann-benchmarks](https://github.com/erikbern/ann-benchmarks/#data-sets) project so you can compare our performance and accuracy against it.
### Detailed Report and Access