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

Wir haben sieben Open-Source-, selbst gehostete Vektordatenbanken als Retrieval-Schicht einer RAG-Pipeline einem Benchmark unterzogen, wobei jede einzeln auf identischen bge-m3-Embeddings und echten medizinischen und technischen Anfragen lief, sodass der Datenbankindex die einzige Variable war. Die Arbeitslast umfasste MedRAG-50k, TechQA-28k und einen Korpus mit 2.25M Vektoren über acht Dimensionen hinweg, von Genauigkeit und Retrieval-Qualität über Geschwindigkeit, Speicher, gefilterte und hybride Suche, Baukosten bis hin zu Live-Churn.

Single-Thread-Geschwindigkeit

Jede Engine wird auf demselben Recall-Niveau bewertet, dem gemeinsamen Arbeitspunkt, an dem ihr Suchparameter (entweder ef oder nprobe) so eingestellt wird, bis sie einen Recall@10 von 0.95 erreicht, was einen fairen Vergleich der Geschwindigkeitswerte ermöglicht.

Auf einem einzelnen Client-Thread liefert Redis 764 QPS auf MedRAG-50k bei 559 MB Spitzen-RAM, der höchste Durchsatz und der niedrigste Speicherverbrauch im Set. Die Single-Thread-Reihenfolge ist Redis 764, Qdrant 377, Milvus 342, Weaviate 341, pgvector 257, Chroma 197, LanceDB 70, eine Spanne von 10x von oben bis unten. LanceDB ist der On-Disk-Ausreißer und tauscht RAM gegen Latenz bei einem p95 nahe 22 ms. Redis bleibt am schnellsten und LanceDB am langsamsten auf TechQA-28k (651 bis 81) und bei 2.25M (495 bis 28), obwohl sich das Mittelfeld bei größerer Skalierung neu sortiert, wo Milvus vom dritten auf den sechsten Platz fällt.

Für RAG bestimmt die Tail-Latenz die Nutzererfahrung stärker als der reine Durchsatz. Die Latenz pro Anfrage, zusammengefasst über 100 Läufe mit 154 Anfragen bei angepasstem Recall, folgt der Durchsatzreihenfolge.

Redis lief mit deaktivierter Persistenz (kein RDB-Snapshot und keine Append-Only-Datei), daher gelten seine Geschwindigkeits- und Speicherwerte für eine flüchtige Konfiguration ohne Dauerhaftigkeit.

Durchsatz unter Nebenläufigkeit

Single-Thread-QPS beantwortet, wie schnell eine einzelne Anfrage ist. Die Produktionsfrage ist der Durchsatz unter vielen gleichzeitigen Clients, und die Antwort hängt davon ab, wie der Client gebaut ist, nicht allein von der Datenbank.

Ein Client mit geschlossenem Regelkreis kann auf zwei Arten betrieben werden, und beide sind in Python-RAG-Apps üblich. Ein einzelner Async- oder Thread-Prozess deserialisiert jedes gleichzeitige Ergebnis (gRPC/protobuf oder RESP) auf einem einzigen GIL, sodass der Client und nicht der Server den Durchsatz begrenzt. Viele Worker-Prozesse (das Muster gunicorn -w N) erhalten jeweils einen eigenen GIL und legen weit mehr Serverkapazität frei. Wir haben beides auf einer Box mit 32 vCPUs bei festem ef=128 gemessen und jeden Punkt Recall-verifiziert.

Wenn die Anfrage-Nebenläufigkeit von 1 auf 512 über bis zu 32 Worker-Prozesse steigt, kreuzen sich die Durchsatzkurven. Redis startet bei einer Anfrage am höchsten und endet am niedrigsten, während Weaviate vom unteren Ende des Feldes auf ein Plateau von 8330 QPS bei 512 Anfragen klettert und dabei bei 32 den Wert 7.114 passiert. Bei einem einzelnen Async-Prozess folgt die Rangfolge stattdessen der Parse-Effizienz des Python-Clients, da Redis’ RESP am leichtesten zu deserialisieren ist und am wenigsten an den GIL verliert.

Die Einzelprozess-Spitze und die 32-Prozess-Spitze jeder Engine sind die Obergrenzen über den gesamten Bereich von 1 bis 512, nicht der Durchsatz bei einer bestimmten Anfragezahl.

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 danach negativ (der Query-Thread-Pool von RediSearch, WORKERS, ist standardmäßig deaktiviert). Weaviate und Milvus (Multithread-Server) sowie pgvector (ein unabhängiges Postgres-Backend pro Verbindung) skalieren über die 32 Kerne. pgvector hat die niedrigste Einzelprozess-Spitze (536) und die zweithöchste 32-Prozess-Spitze (4832). Unter einem Budget von p99 unter 100ms ist die Mehrprozess-Reihenfolge Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

Der schwerere gRPC-Parse von Qdrant macht seinen Co-located-Wert clientgebunden statt zu einer Servergrenze, da allein die Prozessanzahl ihn von 455 QPS in einem Prozess auf 1859 bei 32 bewegt. Chroma und LanceDB wurden aus dem Mehrprozess-Lauf herausgehalten. Chroma fixiert ef beim Anlegen der Collection und skaliert negativ, mit einem p99 von 13 Sekunden bei 512 Anfragen, und LanceDB ist eingebettet, daher trifft die Netzwerk-Client-Geschichte nicht zu.

Speicherbedarf

Bei 50k Vektoren reicht der Spitzen-RAM 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.25M, wo sich der Kompromiss zwischen In-Memory und Disk öffnet.

Der Spitzen-RAM bei 2.25M liegt über die fünf In-Memory-Engines hinweg zwischen 17.0 GB (Milvus) und 62.4 GB (Chroma), eine Spanne von 3.7x oder 7.5 GB bis 27.7 GB pro Million Vektoren. Milvus bleibt am schlankesten, weil es den Index auf die Disk auslagert (nach DiskANN-Art), während die reinen RAM-HNSW-Engines am schnellsten wachsen; daher ist Milvus, das bei 50k (3.300 MB) das schwerste ist, bei 2.25M (17.0 GB) das schlankeste, und Chroma ist mit 62.4 GB das schwerste.

Die beiden On-Disk-Engines stehen außerhalb dieses RAM-Vergleichs, da ihr Footprint auf Disk statt im RAM liegt. pgvector hält einen 18.4 GB großen On-Disk-Index und LanceDB einen von 12.0 GB bei 2.25M; ihr Serving-RAM ist ein Page Cache über diesem Index und nicht das gesamte Working Set, das nicht gemessen wurde. Ein Vorbehalt betrifft auch die In-Memory-Werte: Sie sind eine Build-and-Serve-Höchstmarke, kein reiner Serving-Footprint, daher ist eine reine Serving-Nachmessung eine offene Verfeinerung.

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

Die anderen sieben Dimensionen messen einen statischen Bulk-Load und lesen dann den Korpus. Echte RAG-Wissensdatenbanken fügen kontinuierlich Dokumente hinzu, aktualisieren und löschen sie, während der Index im Hintergrund zusammenführt. Diese Churn-Arbeitslast lief auf MedRAG-50k auf einer separaten Box mit 8 vCPUs; daher ist ihr Durchsatz nur innerhalb dieses Abschnitts gültig und nicht mit den 32-Kern-Geschwindigkeitswerten vergleichbar. Die Korrektheitssignale (Recall- und Tombstone-Prüfungen) sind hardwareunabhängig.

Aktualität (Read-after-Write). Bei der Konsistenzeinstellung, mit der jede Engine konfiguriert wurde, ist jede einzelne read-after-write. Ein neu geschriebenes Dokument ist sofort durchsuchbar, und null von etwa 150 Schreibvorgängen sind nicht sichtbar. Die Latenz von der Schreibbestätigung bis zur Sichtbarkeit in der Suche 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 gelangt später in den persistenten HNSW-Graph), daher sind die 12 ms die Durchsuchbarkeit des wachsenden Segments, ein gültiges nutzerseitiges Read-after-Write.

Schreib- und Lesevorgänge unter Mischlast. Mit einem Writer, der 150 Schreibvorgänge/s anstrebt, und sechs Readern, die 60 Sekunden lang abfragen, blieb der Read-Recall für jede Engine zwischen 0.96 und 1.00, und kein Index verschlechterte sich unter gleichzeitigen Schreibvorgängen. Der Schreibdurchsatz einzelner Zeilen trennt die Engines um 57x, und die Reihenfolge ähnelt der Umkehrung der statischen Build-Rangfolge.

LanceDB zahlt einen Copy-on-Write-Commit pro Zeile und Chroma einen HTTP-Add pro Zeile, weshalb die schnellsten statischen Builder unter Churn am langsamsten sind. Der Schreibdurchsatz ist hier die erreichte Rate gegenüber einem Ziel von 150/s unter gleichzeitigen Lesevorgängen, daher sind die schnellen Engines nahe 150 gedeckelt, statt ihre Spitze zu zeigen. Dies ist als Online-Schreibverhalten einzelner Zeilen mit hoher Frequenz zu verstehen, nicht als Batch-Ingestion, die der Designpunkt dieser Engines ist und hier nicht getestet wurde.

Löschung und Kompaktierung. Beim Löschen eines zufälligen 20 %-Anteils des Live-Sets und erneuten Einfügen von 20 % neuen Dokumenten betrug das Tombstone-Leck für jede Engine null. Eine gelöschte ID tauchte in der Suche nie wieder auf, und Recall@10 blieb nach dem gesamten Zyklus zwischen 0.97 und 1.00. Die Korrektheit bleibt unter Churn überall erhalten. Die Kosten unterscheiden sich je Engine. pgvector zahlt eine 53-Sekunden-VACUUM und Milvus eine 11-Sekunden-Kompaktierung, während bei den langsam schreibenden Engines das erneute Einfügen dominiert (Chroma 276 s, LanceDB 1139 s für etwa 6.000 Dokumente).

Weaviate lief in diesem Abschnitt mit 3.000 anfänglichen Dokumenten statt 30.000 (die synchrone Bulk-Aufnahme ist auf der kleinen Box langsam), daher liegt seine Lese-QPS bei einem kleineren Korpus. Bei dieser Skalierung beträgt seine korrigierte Aktualität etwa 5 ms und seine Schreibrate etwa 102/s, was beides ins Mittelfeld einordnet.

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 DB indexiert hat), den der approximative Index zurückgegeben hat. Er isoliert die Datenbank (Indextyp, ef/nprobe, Implementierung), nicht das Embedding.

nDCG@10 ist ein positionsgewichteter Wert von 0 bis 1 dafür, ob das menschlich gekennzeichnete korrekte Dokument nahe dem oberen Ende der Ergebnisliste landet. Er misst die End-to-End-Retrieval-Relevanz, die größtenteils eine Eigenschaft des Embedding-Modells ist, das hier über alle Engines konstant gehalten wird.

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

Ergebnisse des Vektordatenbank-Benchmarks

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); die Näherung der Datenbank kostet also höchstens 0.023 nDCG-Punkte an Antwortqualität.

Unter diesem Embedding, Korpus, k=10 und dem Arbeitspunkt 0.95 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 oben. Die Indexwahl beginnt die Qualität bei Recall@10 = 0.99 oder höher zu bewegen, bei größerem k, bei weit größeren Korpora oder bei quantisierten Indizes.

Die Retrieval-Zuverlässigkeit variiert stärker danach, was eine Anfrage verlangt, als danach, welche Datenbank sie beantwortet. Über die 154 MedRAG-Anfragen beim Exakt-kNN-Orakel erzielen Faktoid-Lookups 0.888 nDCG@10, konditionale Fragen 0.836, vergleichende Fragen 0.779 und Fragen zur Existenz von Klauseln 0.763. Die 0.125-Lücke zwischen Faktoid und Klausel-Existenz ist identisch über alle sieben Engines vorhanden.

Metadatenfilter kosten Durchsatz, nicht Recall

Mit einem angewendeten Metadaten-Prädikat bleibt der Worst-Case-Recall@10 über ein Raster von Selektivität (1/5/20/50 %) und Prädikatkorrelation (verteilt und gehäuft) zwischen 0.968 (Redis) und 1.00 (Weaviate, pgvector, LanceDB). Der Unterschied liegt im gefilterten Durchsatz.

Der Unterschied liegt im Durchsatz. Chroma (11-19 QPS) und pgvector (10-56 QPS) halten den Recall bei 20- bis 40x niedrigerem gefiltertem Durchsatz als der Rest. Milvus behält den höchsten Worst-Case-Recall (0.984) mit 268 bis 732 QPS über alle Selektivitäten, während Redis bei niedriger Selektivität am schnellsten läuft (1.374 QPS bei 1 %), bei einer niedrigeren Recall-Untergrenze (0.968). Bei 1-5 % Selektivität ist ein Recall von 1.00 größtenteils der exakte Full-Scan-Zweig des Query-Planers unterhalb der Full-Scan-Schwelle jeder Engine, nicht filterbares HNSW, wie pro Engine offengelegt.

*LanceDBs gefilterter Recall wurde zunächst mit 0.24 bei gehäuften Filtern gemessen und dann zurückgezogen. Der Sweep variierte ef, aber LanceDBs Recall-Regler ist nprobes, daher lief es mit einem Standardwert von etwa 9 % der Partitionen. Bei korrekten nprobes neu gemessen, erholt sich der gehäufte Recall@10 von 0.24 auf 0.76 (nprobes=128) und auf etwa 1.00 (nprobes=256), bei 3- bis 5x niedrigerem QPS. LanceDB hält den gefilterten Recall, aber langsam. Eine recall-abgestimmte Nachmessung des gefilterten Durchsatzes auf demselben Host steht noch aus, daher ist LanceDBs gefilterter QPS nicht aufgeführt.

Hybride Suche bringt bis zu 0.067 nDCG

Das Hinzufügen eines Standard-BM25-Keyword-Arms und dessen Fusion mit dem dichten Arm durch Reciprocal Rank fusion (RRF, k=60) erhöht nDCG@10 für jede Engine mit Keyword-Arm um 0.030 bis 0.067. Auf MedRAG sind der dichte und der BM25-Arm einzeln nahezu gleich stark (jeweils etwa 0.80), daher gleicht die Steigerung die Fehler jedes Arms aus, statt dass ein Arm dominiert.

Die Engines mit einem starken BM25-Arm profitieren am meisten, und pgvector sowie Weaviate profitieren weniger, entsprechend ihren schwächeren Keyword-Arms (0.740 und 0.782). Kein Hybrid einer Engine fällt unter seinen dichten Arm, sobald korrekt gemessen wird.

Was die Engines trennt, ist native fusion gegenüber clientseitigen Roundtrips, von Milvus mit 340 QPS nativ bis pgvector mit 12 QPS clientseitig. Vier Engines fusionieren nativ (Qdrant, Milvus, Weaviate, LanceDB). Redis führt natives BM25 und KNN aus, aber in dieser Version keine serverseitige fusion, daher macht der Client zwei Roundtrips und fusioniert in Python. pgvector hat keine fusion-API, fusioniert clientseitig, und sein Keyword-Arm ist Postgres ts_rank (Termfrequenz mit Längennormalisierung, kein IDF), was mit einem OR-Volltextscan mit 12 QPS läuft. Selbst gehostetes Chroma hat überhaupt keine bewertete Stichwortsuche (BM25 ist eine Chroma-Cloud-Funktion), daher hat es keine Hybrid-Zeile.

Index-Bauzeit erstreckt sich über 13x

Bei 50k Vektoren dauert der Indexbau zwischen 7 Sekunden (LanceDB) und 11 bis 13 Sekunden (Weaviate, Milvus) bis zu 88 Sekunden (pgvector). Bei 2.25M erreicht die Spanne 13x. LanceDB und Milvus werden in 7 bis 8 Minuten fertig, gegenüber 44 Minuten für Redis und 92 für pgvector. Normalisiert auf den Box-Tarif liegen die Baukosten zwischen €0.04 pro 1M Vektoren (LanceDB) und €0.05 (Milvus) bis €0.58 (pgvector). Der Bau ist eine einmalige Kostenposition, die nur bei erneuter Indexierung des Korpus wieder anfällt.

Retrieval-Qualität bei 2.25M Vektoren

Um die Qualität bei Skalierung zu testen und gleichzeitig echte menschliche Labels beizubehalten, haben wir einen Korpus mit 2.25M Vektoren aufgebaut. Er kombiniert die 50k gelabelten MedRAG-Dokumente mit 2.2M PubMed-Distraktoren, alle im selben bge-m3-Raum und integritätsgeprüft, sodass kein Distraktor ein fehlgelabeltes Ziel ist. Übliche ANN-Datensätze im Milliardenbereich enthalten keine menschlichen Relevanzlabels und können daher nicht zeigen, was als Nächstes passiert.

Der geometrische ANN-Recall bleibt bei Skalierung stabil. Jede Engine erreicht bei 2.25M weiterhin einen Recall@10 über 0.973 (Qdrant und Milvus bei 0.999), der Index findet also die echten nächsten Vektoren. Die semantische Antwortqualität bleibt nicht stabil. nDCG@10 fällt für jede Engine von etwa 0.81 bei 50k auf etwa 0.56 bei 2.25M, weil das korrekte Dokument unter 2.2M Distraktoren begraben ist.

Der Einbruch ist kein Datenbankeffekt. Er trifft das Exakt-kNN-Orakel identisch (Orakel-nDCG@10 bei 2.25M beträgt 0.572, und jede Engine liegt an dieser Obergrenze bei etwa 0.55 bis 0.57). Ob die Ursache die Obergrenze des Embeddings, Korpus-Mehrdeutigkeit oder Einzel-Positiv-Labels sind, die jetzt relevante Beinahe-Duplikate übersehen, wird hier nicht entschieden. Die Trennung dieser Ursachen erfordert menschliches Neulabeln der neu am höchsten gerankten Dokumente. Die berichtbare Tatsache ist, dass die Skalierung des Korpus um 45x etwa ein Drittel der Antwortqualität ausgelöscht hat (nDCG@10 von 0.81 auf 0.56), während jeder ANN-Index weiterhin 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 Produktiv-RAG-Einsatz trennen auch die nicht gemessenen Achsen (Dauerhaftigkeit, Hochverfügbarkeit, Zugriffskontrolle) diese Engines. Diese Fähigkeiteninventur ist dokumentenbasiert und stammt aus der offiziellen Dokumentation jeder Engine in der gebenchmarkten Open-Source-Edition. Sie ist eine Fähigkeiteninventur, kein Chaostest. Tatsächliche Failover-Zeit, das Datenverlustfenster bei Absturz-Wiederherstellung und die Mandantenisolation unter Last werden hier nicht gemessen.

Unter den sieben bietet allein pgvector 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 Milvus’ Hochverfügbarkeit im schwergewichtigeren verteilten Modus liegt, nicht im hier gemessenen Standalone-Build. Keine der sieben verschlüsselt On-Disk-Daten nativ. Alle verlassen sich auf Disk- oder Volume-Verschlüsselung auf Infrastrukturebene.

Für mandantenfähiges RAG, bei dem ein Filter zugleich als Zugriffskontrollgrenze dient, können Qdrant, Milvus, Weaviate und pgvector die Mandantenisolation innerhalb der Datenbank durchsetzen. Chroma und eingebettetes LanceDB verlagern das in die Anwendung. Ein korrekter Pre-Filter liefert zu wenige Ergebnisse – ein Vollständigkeitsrisiko –, statt die Dokumente eines anderen Mandanten preiszugeben. Ein mandantenübergreifendes Leck würde einen fehlerhaften Post-Filter erfordern, den keine dieser Engines verwendet hat.

So funktioniert die approximative Nächste-Nachbarn-Suche

Eine Vektordatenbank speichert einen hochdimensionalen Vektor pro Dokument und gibt zu einem Abfragevektor die k nächsten anhand einer Distanzmetrik zurück (hier Kosinus über L2-normalisierte Vektoren). Die exakte Nächste-Nachbarn-Suche vergleicht die Anfrage 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 Nächste-Nachbarn-Indizes (ANN) geben etwas Genauigkeit auf, um nur einen Bruchteil der gespeicherten Vektoren zu durchsuchen. Die dominierende Struktur bei diesen Engines ist HNSW, ein geschichteter Näherungsgraph, der von einem groben Einstiegspunkt in eine dichte Nachbarschaft wandert und dabei eine begrenzte Zahl von Kandidaten besucht, die durch einen Suchregler 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.

Weil dieser Regler kontinuierlich Recall gegen Geschwindigkeit tauscht, ist ein Vergleich zweier Engines bei einer festen Einstellung irreführend, da eine Engine möglicherweise mehr Genauigkeit für ihre Geschwindigkeit aufwendet. Der faire Vergleich variiert den Regler, zeichnet die Recall-gegen-QPS-Kurve jeder Engine auf und liest sie alle beim gleichen Recall ab. Dieser Recall-abgestimmte Punkt (hier Recall@10 = 0.95) ist die Stelle, an der die QPS-, Latenz- und Speicherwerte in diesem Benchmark entnommen werden.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Benchmark-Methodik

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 gepinnten Docker-Images. Redis lief mit deaktivierter Persistenz (kein RDB-Snapshot und keine Append-Only-Datei).

Hardware. Eine Hetzner CCX53 (32 dedizierte vCPUs, 128 GB RAM, NVMe, nbg1) für Genauigkeit, Geschwindigkeit, Speicher, gefilterte Suche und Build, jeweils nur ein Container 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. Die Anfragen tragen menschliche Einzel-Positiv-Labels (target_doc_id).

Korpora. MedRAG-50k (154 Anfragen) und TechQA-28k (151 Anfragen) für die Retrieval-Qualität sowie ein Korpus mit 2.25M Vektoren (50k gelabelt plus 2.2M Distraktoren) für die Skalierungsstufe. Die Hybrid-Dimension wurde lokal auf Docker erneut ausgeführt, daher ist ihre QPS nur zwischen den Hybrid-Zeilen vergleichbar, nicht mit den Box-Werten. Ihre nDCG- und Δ-Werte sind hardwareunabhängig.

Statistik. 100+ Läufe pro Messung, IQR-Ausreißerbereinigung bei 3.0x, Zeitmessung perf_counter_ns. Anfragepools von 154 bis 246 begrenzen die Tail-Berichterstattung auf p95, gelegentlich p99. p99.9 ist bei diesen Stichprobenumfängen undefiniert.

Zweifache 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 echten nächsten Vektoren zurückgegeben hat, und isoliert damit die Datenbank. Die semantische Ground Truth (nDCG@10, MRR, Hit@k gegen menschliche Labels) fragt, ob die zurückgegebenen Dokumente relevant sind, was größtenteils das konstant gehaltene Embedding ist. 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 als Geschwindigkeit und Speicher bei abgestimmtem ANN-Recall, und die Δ-Brücke übersetzt ihren Näherungsverlust in Antwortqualität.

Korrektheitsanker. Jedes Engine-spezifische Rezept (Filter und Hybrid) wurde in der exakten Version aus der offiziellen Dokumentation entnommen und vor der Implementierung adversariell überprüft. 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 entfernt abschneidet, auf einen Harness-Bug hinweist und nicht auf einen Befund. Diese Absicherung markierte drei Messfehler im ersten Durchgang, alle in unserem Harness (ein Async-Index-Timing-Artefakt bei Weaviate, eine falsche Postgres-Ranking-Funktion und ein SQL-fusion-Bug, der HNSW seine ef-Einstellung ignorieren ließ), die wir behoben, indem wir alle sieben Engines in einer konsistenten Umgebung neu gemessen haben, wobei die fünf bereits korrekten Engines ihre Zahlen exakt reproduzierten. Die Nebenläufigkeits- und Churn-Dimensionen tragen denselben Anker (Recall- und Tombstone-Prüfungen), sodass kein berichteter Wert schnell-aber-falsch ist.

Statistische Signifikanz

Jede berichtete Zahl ist eine Bootstrap-Punktschätzung über 100+ Läufe, mit einem 95 %-Konfidenzintervall aus 1.000 Resamples, und ein Unterschied gilt als real, wenn sich die beiden Intervalle nicht überschneiden.

Der Hybrid-Anstieg ist die knappe Entscheidung, daher sind seine Intervalle der ausschlaggebende Beleg. Vier Engines liegen klar über null und zwei nicht:

Die Retrieval-Genauigkeit ist dieselbe Regel, nur andersherum gelesen. Die nDCG@10-Werte der sieben Engines liegen innerhalb überlappender Intervalle über eine Spanne von 0.014 verteilt, daher gewinnt keine – genau das bedeutet der Gleichstand. Die Geschwindigkeits- und Speicherreihenfolgen liegen weit außerhalb dieser Unsicherheit, mit Abständen (10x Single-Thread-Durchsatz, 3.7x Spitzenspeicher), die das Bootstrap-Rauschen in den Schatten stellen.

Getestete Engines

Einschränkungen

Redis lief mit deaktivierter Persistenz, daher würde eine AOF-fsync-Konfiguration seine Schreiblatenz und seinen Footprint gegenüber den hier berichteten flüchtigen Werten verändern.

Menschliche Labels sind einzelpositiv (ein korrektes Dokument pro Anfrage), ohne abgestufte Relevanz oder Übereinstimmung zwischen Annotatoren, daher tragen nDCG@10, MRR@10 und Hit@10 bei diesen Daten ein nahezu identisches Signal. Das Embedding wird absichtlich konstant gehalten. Embedding-Familien, Dimensionen und mehrsprachiges Verhalten sind ein eigener Benchmark. Dieser Lauf isoliert die Retrieval-Schicht. Die Reranker- (Cross-Encoder) und LLM-Antwortgenerierungsstufen einer RAG-Pipeline sind außerhalb des Umfangs. Verwaltete Cloud-Engines (Pinecone, Zilliz und andere) sind eine spätere Phase. Der Dauerhaftigkeits- und Sicherheitsvergleich ist dokumentenbasiert und nicht chaostestet.

Weiterführende Literatur

• Benchmark für Embedding-Modelle
• Reranker-Benchmark
• Vektordatenbank-Rechner
• Open-Source-Embedding-Modelle
• Mehrsprachige Embedding-Modelle
• Multimodale Embeddings
• Agentische RAG-Frameworks

Zitieren Sie diesen Benchmark

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{sari2026,
  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}
}

Änderungsprotokoll

3 Aktualisierungen

1. 202617. Jul

   Faiss wurde in der Vektordatenbank-Benchmark-Liste durch LanceDB ersetzt.

2. 27. Feb

   Aktuelle Updates zu Milvus, Qdrant und Chroma hinzugefügt.

3. 202514. Aug

   Ein neuer Abschnitt, „Hauptmerkmale quelloffener Vektordatenbanken“, wurde dem Artikel hinzugefügt.

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenwissenschaftler bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

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