Vektordatenbank-Benchmark: 7 Open-Source-Engines für RAG

Wir haben sieben selbst gehostete Open-Source-Vektordatenbanken als Retrieval-Schicht einer RAG-Pipeline getestet, wobei jede einzeln mit identischen bge-m3-Embeddings und echten medizinischen sowie technischen Abfragen lief, sodass der Datenbankindex die einzige Variable war. Der Workload umfasste MedRAG-50k, TechQA-28k und einen Korpus von 2,25 Mio. Vektoren über acht Dimensionen hinweg, von Genauigkeit und Retrieval-Qualität über Geschwindigkeit, Speicher, gefilterte und hybride Suche, Build-Kosten bis hin zum Live-Churn.

Single-Thread-Geschwindigkeit

Jede Engine wird bei demselben Recall-Niveau bewertet, dem gemeinsamen Betriebspunkt, an dem der Suchparameter (entweder ef oder nprobe) so angepasst wird, dass ein Recall@10 von 0,95 erreicht wird, was einen fairen Vergleich der Geschwindigkeitszahlen ermöglicht.

Bei einem einzelnen Client-Thread liefert Redis 764 QPS auf MedRAG-50k mit einem RAM-Spitzenverbrauch von 559 MB, der höchste Durchsatz und der niedrigste Speicherverbrauch im Testfeld. Die Single-Thread-Reihenfolge lautet Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, eine Spanne von 10x von oben nach unten. LanceDB ist der On-Disk-Ausreißer und tauscht RAM gegen Latenz bei einem p95 nahe 22 ms. Die Reihenfolge hält auch bei TechQA-28k (Redis 651 bis LanceDB 81) und bei 2,25 Mio. (Redis 495 bis LanceDB 28).

Für RAG beeinflusst die Tail-Latenz die Benutzererfahrung stärker als der reine Durchsatz. Die Latenz pro Abfrage, aggregiert über 100 Durchläufe von 154 Abfragen bei angeglichenem Recall, folgt der Durchsatz-Reihenfolge.

Redis lief mit deaktivierter Persistenz (kein RDB-Snapshot oder Append-Only-File), sodass sich die Geschwindigkeits- und Speicherwerte auf eine flüchtige Konfiguration ohne Dauerhaftigkeit beziehen.

Durchsatz unter Parallelität

Die Single-Thread-QPS geben an, wie schnell eine Abfrage ist. In der Produktion geht es um den Durchsatz unter vielen gleichzeitigen Clients, und die Antwort hängt davon ab, wie der Client aufgebaut ist, nicht allein von der Datenbank.

Ein Closed-Loop-Client kann auf zwei Weisen betrieben werden, und beide sind in Python-RAG-Apps üblich. Ein asynchroner oder mit Threads arbeitender Prozess deserialisiert jedes gleichzeitige Ergebnis (gRPC/protobuf oder RESP) auf einem einzigen GIL, sodass der Client, nicht der Server, den Durchsatz begrenzt. Mehrere Worker-Prozesse (das gunicorn -w N-Muster) erhalten jeweils ihren eigenen GIL und legen so weit mehr von der Serverkapazität frei. Wir haben beides auf einer Box mit 32 vCPUs bei einem festen ef=128 gemessen und jeden Punkt auf Recall überprüft.

Wenn die Anfrage-Parallelität von 1 auf 512 bei bis zu 32 Worker-Prozessen steigt, überschneiden sich die Durchsatzlinien. Redis startet bei einer Anfrage am höchsten und endet am niedrigsten, während Weaviate vom Ende des Feldes auf ein Plateau von 8330 QPS bei 512 Anfragen klettert und dabei 7.114 bei 32 passiert. Bei einem einzelnen asynchronen Prozess folgt die Rangfolge stattdessen der Effizienz des Parsens durch den Python-Client, da Redis' RESP am einfachsten zu deserialisieren ist und am wenigsten durch den GIL verliert.

Der Single-Prozess-Peak und der 32-Prozess-Peak jeder Engine sind die Obergrenzen über den gesamten 1-bis-512-Durchlauf, nicht der Durchsatz bei einer bestimmten Anfragenanzahl.

Redis hält die niedrigste Einzelabfrage-Latenz im Set (etwa 1,6 ms), und sein Single-Thread-Suchkern sättigt bei etwa 1642 QPS bei 32 gleichzeitigen Anfragen und skaliert dann negativ darüber hinaus (RediSearch's WORKERS Query-Thread-Pool ist standardmäßig deaktiviert). Weaviate und Milvus (Multi-Threaded-Server) und pgvector (ein unabhängiges Postgres-Backend pro Verbindung) skalieren über die 32 Kerne. pgvector hat den niedrigsten Single-Prozess-Peak (536) und den zweithöchsten 32-Prozess-Peak (4832). Bei einem Budget von p99-unter-100 ms lautet die Multi-Prozess-Reihenfolge Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

Das schwergewichtigere gRPC-Parsing von Qdrant macht die co-lokalisierte Zahl eher client-gebunden als serverlimitiert, da die Prozessanzahl allein sie von 455 QPS auf einem Prozess auf 1859 auf 32 anhebt. Chroma und LanceDB wurden vom Multi-Prozess-Lauf ausgeschlossen. Chroma fixiert ef bei der Collection-Erstellung und skaliert negativ, mit einem p99 von 13 Sekunden bei 512 Anfragen, und LanceDB ist eingebettet, sodass die Netzwerk-Client-Geschichte nicht zutrifft.

Speicherbedarf

Bei 50k Vektoren reicht der RAM-Spitzenverbrauch von 559 MB (Redis, In-RAM, Persistenz aus) bis 3.300 MB (Milvus), mit Weaviate bei 1.201, LanceDB bei 1.574, Chroma bei 1.800 und pgvector bei 2.024. Die Rangfolge ändert sich bei 2,25 Mio., wo sich der Kompromiss zwischen In-Memory und On-Disk auftut.

Der RAM-Spitzenverbrauch bei 2,25 Mio. reicht bei den fünf In-Memory-Engines von 17,0 GB (Milvus) bis 62,4 GB (Chroma), eine Spanne von 3,7x, oder 7,5 GB bis 27,7 GB pro Million Vektoren. Milvus bleibt am schlanksten, weil es den Index auf die Platte auslagert (DiskANN-Stil), während die reinen RAM-HNSW-Engines am schnellsten wachsen, sodass Milvus, das schwerste bei 50k (3.300 MB), das schlankste bei 2,25 Mio. (17,0 GB) ist, mit Chroma als schwerstem bei 62,4 GB.

Die beiden On-Disk-Engines stehen außerhalb dieses RAM-Vergleichs, da ihr Footprint auf der Platte und nicht im RAM liegt. pgvector hält einen 18,4 GB On-Disk-Index und LanceDB einen von 12,0 GB bei 2,25 Mio., und ihr Serving-RAM ist ein Page-Cache über diesem Index und nicht das vollständige Working Set, was nicht gemessen wurde. Ein Vorbehalt besteht auch bei den In-Memory-Zahlen. Sie sind ein Build-and-Serve-Höchststand, kein reiner Serving-Footprint, sodass eine reine Serving-Nachmessung eine offene Verfeinerung darstellt.

Aktualität, Schreibvorgänge und Löschungen unter Live-Churn

Die anderen sieben Dimensionen messen einen statischen Bulk-Load-und-dann-Lese-Korpus. Echte RAG-Wissensdatenbanken fügen kontinuierlich Dokumente hinzu, aktualisieren und löschen sie, während der Index im Hintergrund zusammenführt. Dieser Churn-Workload lief auf MedRAG-50k auf einer separaten 8-vCPU-Box, sodass sein Durchsatz intern für diesen Abschnitt gilt und nicht mit den 32-Kern-Geschwindigkeitszahlen vergleichbar ist. Die Korrektheitssignale (Recall- und Tombstone-Prüfungen) sind hardwareunabhängig.

Aktualität (Read-after-Write). Jede Engine ist Read-after-Write. Ein neu geschriebenes Dokument ist sofort durchsuchbar, wobei null von etwa 150 Schreibvorgängen nicht sichtbar sind. Die Latenz von der Schreibbestätigung bis zur Suchbarkeit beträgt 2 ms p50 für Redis, 4 ms für Weaviate, 9 ms für Qdrant, 12 ms für Milvus, 14 ms für pgvector, 31 ms für LanceDB und 41 ms für Chroma. Milvus findet die neue Zeile durch einen Strong-Consistency-Scan des noch nicht versiegelten wachsenden Segments (der Vektor tritt später in den persistenten HNSW-Graphen ein), sodass seine 12 ms die Suchbarkeit des wachsenden Segments darstellen, ein gültiges benutzerseitiges Read-after-Write.

Schreib- und Lesevorgänge unter gemischter Last. Mit einem Writer, der 150 Schreibvorgänge/s anstrebt, und sechs Readern, die 60 Sekunden lang abfragen, hielt der Lese-Recall für jede Engine zwischen 0,96 und 1,00, und kein Index verschlechterte sich unter gleichzeitigen Schreibvorgängen. Der Schreibdurchsatz pro einzelner Zeile trennt die Engines um den Faktor 57, und die Reihenfolge ist nahezu umgekehrt zur Rangfolge des statischen Builds.

LanceDB zahlt einen Copy-on-Write-Commit pro Zeile und Chroma einen HTTP-Add pro Zeile, weshalb die schnellsten statischen Builder unter Churn die langsamsten sind. Der Schreibdurchsatz hier ist die erreichte Rate gegenüber einem Ziel von 150/s unter gleichzeitigen Lesevorgängen, sodass die schnellen Engines nahe 150 gedeckelt sind, anstatt ihren Spitzenwert zu zeigen. Lesen Sie dies als einzelzeiliges, hochfrequentes Online-Schreibverhalten, nicht als Batch-Ingestion, was der Design-Schwerpunkt dieser Engines ist und hier nicht getestet wurde.

Löschen und Kompaktierung. Beim Löschen von zufälligen 20% des Live-Sets und Wiedereinfügen von 20% neuen Dokumenten war das Tombstone-Leck bei jeder Engine null. Eine gelöschte ID tauchte nie wieder in der Suche auf, und Recall@10 blieb nach dem vollständigen Zyklus bei 0,97 bis 1,00. Die Korrektheit bleibt unter Churn überall bestehen. Die Kosten unterscheiden sich je nach Engine. pgvector zahlt ein 53-Sekunden VACUUM und Milvus eine 11-Sekunden Kompaktierung, während bei den langsam schreibenden Engines die Wiederaufnahme dominiert (Chroma 276 s, LanceDB 1139 s für etwa 6.000 Dokumente).

Weaviate führte diesen Abschnitt mit 3.000 Initialdokumenten anstelle von 30.000 aus (seine synchrone Bulk-Aufnahme ist auf der kleinen Box langsam), sodass seine Lese-QPS auf einem kleineren Korpus basieren. Bei dieser Skala beträgt seine korrigierte Aktualität etwa 5 ms und seine Schreibrate etwa 102/s, was beides im Mittelfeld platziert.

Metriken erklärt

ANN Recall@10 ist der Anteil der 10 wahren nächsten Vektoren (gemäß einem exakten Brute-Force-kNN-Orakel über dieselben Embeddings, die die DB indiziert hat), die der approximative Index zurückgegeben hat. Er isoliert die Datenbank (Indextyp, ef/nprobe, Implementierung), nicht das Embedding.

nDCG@10 ist ein positionsgewichteter 0-bis-1-Score, der angibt, ob das menschlich gekennzeichnete korrekte Dokument nahe der Spitze der Ergebnisliste landet. Er misst die End-to-End-Retrieval-Relevanz, die zu etwa 90% vom Embedding-Modell abhängt, das hier über alle Engines konstant gehalten wurde.

Δ (Delta-Brücke) ist der nDCG@10 des Orakels minus den nDCG@10 der Datenbank bei einer gegebenen Sucheinstellung. Sie übersetzt den Approximationsfehler jeder Engine in die Antwortqualität, die ihre Geschwindigkeit kostet, berichtbar, weil wir sowohl ein Orakel als auch menschliche Labels haben.

Erkenntnisse aus dem Vektordatenbank-Benchmark

Die sieben Engines sind bei der Retrieval-Genauigkeit gleichauf

Bei Recall@10 = 0,95 auf MedRAG-50k liegt nDCG@10 zwischen 0,803 (pgvector) und 0,817 (LanceDB), eine Spanne von 0,014. Die Delta-zum-Orakel-Brücke reicht von 0,009 (LanceDB) bis 0,023 (pgvector), sodass die Approximation der Datenbank höchstens 0,023 nDCG-Punkte an Antwortqualität kostet.

Unter diesem Embedding, Korpus, k=10 und 0,95 Betriebspunkt bewegt die Datenbankwahl nDCG@10 um höchstens 0,014, gegenüber der 10x-Spanne beim Single-Thread-Durchsatz und der 3,7x-Spanne beim Spitzenspeicher, die oben gezeigt wurden. Die Indexwahl beginnt, die Qualität bei Recall@10 = 0,99 oder höher, bei größerem k, bei weitaus größeren Korpora oder bei quantisierten Indizes zu beeinflussen.

Die Retrieval-Zuverlässigkeit variiert stärker danach, was eine Abfrage fragt, als danach, welche Datenbank sie beantwortet. Über die 154 MedRAG-Abfragen beim Exakt-kNN-Orakel erzielen Faktoid-Lookups 0,888 nDCG@10, konditionale Fragen 0,836, Vergleichsfragen 0,779 und Existenz-von-Klauseln-Fragen 0,763. Die Lücke von 0,125 zwischen Faktoid und Existenz-von-Klauseln ist bei allen sieben Engines identisch vorhanden.

Metadatenfilter kosten Durchsatz, nicht Recall

Bei Anwendung eines Metadaten-Prädikats bleibt der Worst-Case Recall@10 zwischen 0,968 (Redis) und 1,00 (Weaviate, pgvector, LanceDB) über ein Raster von Selektivität (1/5/20/50%) und Prädikatkorrelation (gestreut und geclustert). Die Trennung liegt im gefilterten Durchsatz.

Milvus erreichte den höchsten gemessenen gefilterten Durchsatz (732 QPS) bei einem gehaltenen Recall von 0,984. Chroma (11-19 QPS) und pgvector (10-56 QPS) halten den Recall bei 20- bis 40-fach niedrigerem gefiltertem Durchsatz. Bei 1-5% Selektivität ist ein Recall von 1,00 größtenteils der exakte Full-Scan-Zweig des Query-Planers unterhalb des jeweiligen Full-Scan-Schwellenwerts der Engine, nicht filterbarer HNSW, offengelegt pro Engine.

*LanceDBs gefilterter Recall wurde zunächst bei 0,24 für geclusterte Filter gemessen und dann zurückgezogen. Der Sweep variierte ef, aber LanceDBs Recall-Knopf ist nprobes, sodass es mit einem Standardwert von etwa 9% der Partitionen lief. Neu gemessen mit korrekten nprobes erholt sich der geclusterte Recall@10 von 0,24 auf 0,76 (nprobes=128) auf etwa 1,00 (nprobes=256), bei 3- bis 5-fach niedrigeren QPS. LanceDB hält gefilterten Recall, langsam. Eine recall-angepasste, auf demselben Host durchgeführte Nachmessung des gefilterten Durchsatzes steht noch aus, daher ist LanceDBs gefilterte QPS nicht aufgeführt.

Hybride Suche fügt bis zu 0,067 nDCG hinzu

Das Hinzufügen eines Standard-BM25-Keyword-Arms und dessen Fusion mit dem dichten Arm durch Reciprocal Rank Fusion (RRF, k=60) hebt nDCG@10 um 0,030 bis 0,067 für jede Engine mit einem Keyword-Arm. Auf MedRAG sind der dichte und der BM25-Arm einzeln nahezu gleich stark (jeweils etwa 0,80), sodass die Steigerung die Fehler jedes Arms korrigiert, anstatt dass ein Arm dominiert.

Das Konfidenzintervall der Steigerung schließt Null für die vier Engines mit einem starken BM25-Arm aus (Qdrant +0,067, LanceDB +0,063, Redis +0,049, Milvus +0,044). Es bleibt positiv, kreuzt aber Null für pgvector (+0,037) und Weaviate (+0,030), deren Keyword-Arme niedriger punkten (0,740 und 0,782). Der Hybrid-Modus keiner Engine fällt unter ihren dichten Arm, sobald er korrekt gemessen wurde.

Was die Engines trennt, ist native Fusion gegenüber clientseitigen Roundtrips, von Milvus mit nativen 340 QPS bis pgvector mit clientseitigen 12 QPS. Vier Engines fusionieren nativ (Qdrant, Milvus, Weaviate, LanceDB). Redis führt natives BM25 und KNN aus, aber keine serverseitige Fusion in dieser Version, sodass der Client zwei Roundtrips durchführt und in Python fusioniert. pgvector hat keine Fusions-API, fusioniert clientseitig, und sein Keyword-Arm ist Postgres ts_rank (Term Frequency mit Längennormalisierung, kein IDF), was mit einem OR-Full-Text-Scan bei 12 QPS läuft. Chroma im Self-Hosted-Betrieb hat überhaupt keine ranked Keyword-Suche (BM25 ist ein Chroma-Cloud-Feature), daher hat es keine Hybrid-Zeile.

Index-Build-Zeit erstreckt sich über 13x

Bei 50k Vektoren dauert der Indexaufbau von 7 Sekunden (LanceDB) und 11 bis 13 (Weaviate, Milvus) bis zu 88 Sekunden (pgvector). Bei 2,25 Mio. erreicht die Spanne 13x. LanceDB und Milvus sind in 7 bis 8 Minuten fertig, gegenüber 44 Minuten für Redis und 92 für pgvector. Normalisiert auf die Box-Rate liegen die Build-Kosten zwischen 0,04 € pro 1 Mio. Vektoren (LanceDB) und 0,05 € (Milvus) bis zu 0,58 € (pgvector). Der Build ist ein einmaliger Kostenfaktor, der nur bei einer Neuindizierung des Korpus erneut anfällt.

Retrieval-Qualität bei 2,25 Mio. Vektoren

Um die Qualität in großem Maßstab zu testen und gleichzeitig echte menschliche Labels zu behalten, haben wir einen Korpus mit 2,25 Mio. Vektoren erstellt. Er kombiniert die 50k gelabelten MedRAG-Dokumente mit 2,2 Mio. Pubmed-Distraktoren, alle im gleichen bge-m3-Raum, integritätsgeprüft, sodass kein Distraktor ein fehlgelabeltes Ziel ist. Standard-ANN-Datensätze im Milliardenbereich enthalten keine menschlichen Relevanz-Labels, daher können sie nicht zeigen, was als Nächstes passiert.

Der geometrische ANN-Recall hält bei Skalierung. Jede Engine erreicht immer noch Recall@10 über 0,973 bei 2,25 Mio. (Qdrant und Milvus bei 0,999), sodass der Index die wahren nächsten Vektoren findet. Die semantische Antwortqualität hält nicht. nDCG@10 fällt für jede Engine von etwa 0,81 bei 50k auf etwa 0,56 bei 2,25 Mio., weil das korrekte Dokument unter 2,2 Mio. Distraktoren begraben wird.

Der Einbruch ist kein Datenbankeffekt. Er trifft das exakte kNN-Orakel identisch (Orakel nDCG@10 bei 2,25 Mio. beträgt 0,572, und jede Engine liegt an dieser Obergrenze um 0,55 bis 0,57). Ob die Ursache die Obergrenze des Embeddings, die Korpus-Ambiguität oder Single-Positive-Labels sind, die nun relevante Near-Duplicates übersehen, wird hier nicht entschieden. Die Trennung dieser Ursachen würde ein menschliches Re-Labeling der neu top-gerankten Dokumente erfordern. Die berichtbare Tatsache ist, dass die Skalierung des Korpus um 45x etwa ein Drittel der Antwortqualität auslöschte (nDCG@10 von 0,81 auf 0,56), während jeder ANN-Index nahezu perfekten Recall meldete, ein Effekt, den ein rein geometrischer Benchmark übersehen würde.

Dauerhaftigkeit, HA und Sicherheit nach Engine

Geschwindigkeit, Speicher und Recall sind die gemessenen Achsen. Für einen produktiven RAG-Einsatz trennen die nicht gemessenen Achsen (Dauerhaftigkeit, Hochverfügbarkeit, Zugriffskontrolle) diese Engines ebenfalls. Diese Fähigkeitsübersicht basiert auf der offiziellen Dokumentation jeder Engine zum Zeitpunkt des Benchmarks in der Open-Source-Edition. Es handelt sich um eine Fähigkeitsübersicht, keinen Chaos-Test. Tatsächliche Failover-Zeit, das Datenverlustfenster bei Crash-Recovery und die Mandantenisolierung unter Last wurden hier nicht gemessen.

Unter den sieben bietet pgvector als einziges Point-in-Time Recovery (durch Postgres WAL-Archivierung) und Row-Level Security. Qdrant, Milvus und Weaviate liefern Replikation und RBAC in ihren Open-Source-Builds, mit dem Vorbehalt, dass die Hochverfügbarkeit von Milvus im schwergewichtigeren Distributed Mode liegt, nicht im hier gemessenen Standalone-Build. Keine der sieben verschlüsselt On-Disk-Daten nativ. Alle verlassen sich auf Platten- oder Volume-Verschlüsselung auf der Infrastrukturebene.

Für mandantenfähiges RAG, wo ein Filter gleichzeitig als Zugriffskontrollgrenze dient, können Qdrant, Milvus, Weaviate und pgvector die Mandantenisolierung innerhalb der Datenbank durchsetzen. Chroma und die eingebettete LanceDB schieben dies an die Anwendung weiter. Ein korrekter Pre-Filter liefert zu wenig, ein Vollständigkeitsrisiko, anstatt die Dokumente eines anderen Mandanten durchsickern zu lassen. Ein mandantenübergreifendes Leck würde einen fehlerhaften Post-Filter erfordern, den keine dieser Engines verwendet hat.

Entdecken Sie weitere unserer Benchmarks und datengestützten Erkenntnisse in der Google-Suche.

Als bevorzugte Quelle hinzufügen

So funktioniert die approximative Nearest-Neighbor-Suche

Eine Vektordatenbank speichert einen hochdimensionalen Vektor pro Dokument und gibt bei einem Suchvektor die k nächsten nach einer Distanzmetrik zurück (hier Kosinus über L2-normalisierten Vektoren). Die exakte Nearest-Neighbor-Suche vergleicht die Abfrage mit jedem gespeicherten Vektor, was korrekt ist, aber linear mit der Korpusgröße skaliert. Bei 50k Vektoren ist das schnell. Bei Millionen ist es zu langsam für das Serving.

Approximative Nearest-Neighbor (ANN)-Indizes geben etwas Genauigkeit auf, um nur einen Bruchteil der gespeicherten Vektoren zu durchsuchen. Die dominierende Struktur dieser Engines ist HNSW, ein geschichteter Proximity-Graph, der von einem groben Einstiegspunkt in eine dichte Nachbarschaft wandert und dabei eine begrenzte Anzahl von Kandidaten besucht, die durch einen Suchknopf festgelegt wird (ef für HNSW, nprobe für IVF). Ein größeres ef besucht mehr Kandidaten, erhöht den Recall und senkt die QPS. Ein kleineres ef bewirkt das Gegenteil.

Da dieser Knopf den Recall kontinuierlich gegen die Geschwindigkeit eintauscht, ist der Vergleich zweier Engines bei einer festen Einstellung irreführend, da eine möglicherweise mehr Genauigkeit für ihre Geschwindigkeit aufwendet. Der faire Vergleich durchläuft den Knopf, zeichnet die Recall-gegen-QPS-Kurve jeder Engine auf und liest sie alle beim gleichen Recall ab. Dieser recall-angepasste Punkt (hier Recall@10 = 0,95) ist der, an dem die QPS-, Latenz- und Speicherwerte in diesem Benchmark gemessen werden.

Methodik des Vektordatenbank-Benchmarks

Engines: Qdrant v1.18.1, Milvus v2.6.0, Weaviate 1.38.0, pgvector 0.8.x (Postgres 17), Chroma 1.5.0, Redis/RediSearch 8.2 und LanceDB 0.34.0, mit fixierten Docker-Images. Redis lief mit deaktivierter Persistenz (kein RDB-Snapshot oder Append-Only-File).

Hardware: Eine Hetzner CCX53 (32 dedizierte vCPUs, 128 GB RAM, NVMe, nbg1) für Genauigkeit, Geschwindigkeit, Speicher, Filter und Build, jeweils ein Container gleichzeitig aktiv, ein frischer Container pro Index-Build und ein co-lokalisierter Single-Thread-Client. Die Live-Churn-Dimension lief auf einer CCX33 (8 vCPUs, 32 GB).

Embedding: bge-m3, 1024-dim, Kosinus auf L2-normalisiertem float32, k=10, Seed 42, byte-identisch über alle Engines hinweg. Abfragen tragen einzelne positive menschliche Labels (target_doc_id).

Korpora: MedRAG-50k (154 Abfragen) und TechQA-28k (151 Abfragen) für die Retrieval-Qualität sowie ein Korpus von 2,25 Mio. Vektoren (50k gelabelt plus 2,2 Mio. Distraktoren) für die Skalierungsstufe. Die Hybrid-Dimension wurde auf lokalem Docker erneut ausgeführt, daher sind ihre QPS innerhalb der Hybrid-Zeilen vergleichbar, nicht mit den Box-Zahlen. Ihr nDCG und Δ sind hardwareunabhängig.

Statistik: 100+ Durchläufe pro Messung, Bootstrap-95%-Konfidenzintervalle (N=1000), IQR-Ausreißerbereinigung bei 3,0x, perf_counter_ns Timing. Ein Gewinn wird angenommen, wenn sich die Intervalle nicht überschneiden. Abfrage-Pools von 154 bis 246 begrenzen die Tail-Berichterstattung auf p95, gelegentlich p99. p99.9 ist bei diesen Anzahlen undefiniert.

Duale Ground Truth. Eine Vektordatenbank hat zwei unabhängige Ground Truths, und dieser Benchmark bewertet beide. Die geometrische Ground Truth (ANN Recall@10 gegen das exakte Brute-Force-Orakel über dieselben Vektoren) fragt, ob der Index die wahren nächsten Vektoren zurückgegeben hat, und isoliert so die Datenbank. Die semantische Ground Truth (nDCG@10, MRR, Hit@k gegen menschliche Labels) fragt, ob die zurückgegebenen Dokumente relevant sind, was zu etwa 90% vom Embedding abhängt, das konstant gehalten wurde. Da das Embedding eingefroren ist, würde ein Ranking der Engines nach rohen semantischen Scores das Embedding ranken. Die Stärke der Datenbank zeigt sich in Geschwindigkeit und Speicher bei angepasstem ANN-Recall, und die Δ-Brücke übersetzt ihren Approximationsverlust in Antwortqualität.

Korrektheitsanker. Jedes Engine-spezifische Rezept (Filter und Hybrid) wurde der offiziellen Dokumentation für die exakte Version entnommen und vor der Codierung adversariell verifiziert. Die Hybrid-Dimension trägt einen unabhängigen BM25-Antwortschlüssel (zwei Referenzen stimmen bei nDCG etwa 0,81 überein), sodass jede Engine, die weit davon abweicht, auf einen Harness-Bug hindeutet, nicht auf ein Ergebnis. Dieser Wächter markierte drei Messfehler im ersten Durchlauf, alle in unserem Harness (ein Async-Index-Timing-Artefakt bei Weaviate, eine falsche Postgres-Ranking-Funktion und ein SQL-Fusions-Bug, der HNSW seine ef-Einstellung ignorieren ließ), die wir durch Neumessung aller sieben Engines in einer konsistenten Umgebung behoben haben, wobei die fünf bereits korrekten Engines ihre Zahlen exakt reproduzierten. Die Parallelitäts- und Churn-Dimensionen tragen denselben Anker (Recall- und Tombstone-Nachprüfungen), sodass kein berichteter Wert schnell-aber-falsch ist.

Getestete Engines

Einschränkungen

Redis lief mit deaktivierter Persistenz, sodass eine AOF-fsync-Konfiguration seine Schreiblatenz und seinen Footprint im Vergleich zu den hier berichteten flüchtigen Zahlen verändern würde.

Die geplante 10 Mio. Systemstufe wurde nicht ausgeführt, daher beträgt die größte erreichte Skalierung 2,25 Mio., und der In-Memory-gegen-On-Disk-Vergleich wird dort und nicht bei 10 Mio. gezeigt.

Menschliche Labels sind Single-Positive (ein korrektes Dokument pro Abfrage), ohne abgestufte Relevanz oder Inter-Annotator-Übereinstimmung, sodass nDCG@10, MRR@10 und Hit@10 auf diesen Daten ein nahezu identisches Signal tragen. Das Embedding wird absichtlich konstant gehalten. Embedding-Familien, Dimensionen und mehrsprachiges Verhalten sind ein separater Benchmark. Dieser Lauf isoliert die Retrieval-Schicht. Die Reranker- (Cross-Encoder) und LLM-Antwortgenerierungsstufen einer RAG-Pipeline sind außerhalb des Geltungsbereichs. Verwaltete Cloud-Engines (Pinecone, Zilliz und andere) sind eine spätere Phase. Der Vergleich von Dauerhaftigkeit und Sicherheit basiert auf der Dokumentation, nicht auf Chaos-Tests.

Weiterführende Literatur

• Top Vektordatenbank für RAG: Qdrant vs Weaviate vs Pinecone
• Beste RAG-Tools, Frameworks und Bibliotheken
• Benchmark von Open-Source-Embedding-Modellen für RAG
• Reranker-Benchmark: Top-8-Modelle im Vergleich
• RAG-Evaluierungstools: Weights & Biases vs Ragas vs DeepEval

Diese Forschung zitieren

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{sar2026,
  author = {Sarı, Ekrem},
  title  = {{Vektordatenbank-Benchmark: 7 Open-Source-Engines für RAG}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/open-source-vector-databases}},
  note   = {AIMultiple. Abgerufen am 17. Juli 2026}
}

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten