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

Wir haben sieben quelloffene, selbst gehostete Vektordatenbanken als Abrufschicht einer RAG-Pipeline getestet, wobei jede einzeln mit identischen bge-m3-Embeddings und realen medizinischen und technischen Anfragen ausgeführt wurde, sodass der Datenbankindex die einzige Variable war. Das Pensum umfasste MedRAG-50k, TechQA-28k und einen 2.25M-Vektor-Korpus über acht Dimensionen, von Genauigkeit und Abrufqualität über Geschwindigkeit, Speicher, gefilterte und hybride Suche, Erstellungskosten 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, dass ein Recall@10 von 0,95 erreicht wird, was einen fairen Vergleich der Geschwindigkeitswerte ermöglicht.

Auf einem einzelnen Client-Thread liefert Redis 764 QPS bei MedRAG-50k mit einem Spitzen-RAM-Verbrauch von 559 MB, 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 10x-Spanne von oben bis unten. LanceDB ist der On-Disk-Ausreißer, der RAM gegen Latenz mit einem p95 von nahe 22 ms eintauscht. Redis bleibt das schnellste und LanceDB das langsamste auf TechQA-28k (651 zu 81) und bei 2.25M (495 zu 28), obwohl sich die Mitte bei größeren Datenmengen neu sortiert, wo Milvus vom dritten auf den sechsten Platz zurückfällt.

Für RAG bestimmt die Tail-Latenz die Benutzererfahrung stärker als der reine Durchsatz. Die Latenz pro Anfrage, gepoolt über 100 Durchläufe von 154 Anfragen bei abgestimmtem Recall, folgt der Durchsatzreihenfolge.

Redis lief mit deaktivierter Persistenz (kein RDB-Snapshot oder Append-Only-File), sodass seine Geschwindigkeits- und Speicherwerte für eine flüchtige Konfiguration ohne Haltbarkeit gelten.

Durchsatz unter Parallelität

Single-Thread-QPS beantwortet, wie schnell eine einzelne Anfrage ist. Die Frage für die Produktion ist der Durchsatz unter vielen gleichzeitigen Clients, und die Antwort hängt davon ab, wie der Client aufgebaut ist, nicht nur von der Datenbank.

Ein Closed-Loop-Client kann auf zwei Arten betrieben werden, und beide sind in Python-RAG-Anwendungen üblich. Ein asynchroner oder Thread-basierter Prozess deserialisiert jedes gleichzeitige Ergebnis (gRPC/protobuf oder RESP) auf einem einzigen GIL, sodass der Client, nicht der Server, den Durchsatz begrenzt. Viele Worker-Prozesse (das gunicorn -w N-Muster) bekommen jeweils ihren eigenen GIL, was viel mehr von der Kapazität des Servers freilegt. Wir haben beides auf einer 32-vCPU-Box mit einem festen ef=128 gemessen und jeden Punkt recall-verifiziert.

Wenn die Anfrageparallelität von 1 auf 512 über bis zu 32 Worker-Prozesse steigt, überschneiden sich die Durchsatzlinien. 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 unterwegs 7.114 bei 32 passiert. Bei einem einzelnen asynchronen Prozess folgt die Rangfolge stattdessen der Parsing-Effizienz des Python-Clients, da das RESP-Protokoll von Redis am leichtesten zu deserialisieren ist und am wenigsten durch den GIL verliert.

Der Spitzenwert jedes Engines mit einem Prozess und mit 32 Prozessen sind die Maximalwerte über den gesamten Bereich von 1 bis 512, nicht der Durchsatz bei einer bestimmten Anzahl von Anfragen.

Redis weist die niedrigste Einzelabfrage-Latenz im Set auf (etwa 1,6 ms), und sein Single-Thread-Suchkern sättigt bei etwa 1642 QPS bei 32 gleichzeitigen Anfragen und skaliert darüber hinaus negativ (der WORKERS-Abfrage-Thread-Pool von RediSearch 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 Einzelprozess-Spitzenwert (536) und den zweithöchsten 32-Prozess-Spitzenwert (4832). Innerhalb eines Budgets von p99 unter 100ms ist die Multi-Prozess-Reihenfolge Weaviate 8290, pgvector 4828, Milvus 4725, Qdrant 1737, Redis 1642.

Die aufwändigere gRPC-Verarbeitung von Qdrant macht das Ergebnis auf demselben Host eher client-gebunden als serverlimitiert, da allein die Prozessanzahl es von 455 QPS auf einem Prozess auf 1859 auf 32 bringt. Chroma und LanceDB wurden vom Mehrprozess-Lauf ausgeschlossen. Chroma legt ef bei der Collection-Erstellung fest und skaliert negativ, mit einem p99 von 13 Sekunden bei 512 Anfragen, und LanceDB ist eingebettet, sodass das Netzwerk-Client-Szenario nicht zutrifft.

Speicherbedarf

Bei 50k Vektoren reicht der Spitzen-RAM-Verbrauch von 559 MB (Redis, im RAM, Persistenz deaktiviert) bis zu 3.300 MB (Milvus), wobei Weaviate bei 1.201, LanceDB bei 1.574, Chroma bei 1.800 und pgvector bei 2.024 liegen. Das Ranking ändert sich bei 2.25M, wo der Trade-off zwischen Arbeitsspeicher und Festplatte zutage tritt.

Der Spitzen-RAM-Verbrauch bei 2.25M reicht über die fünf In-Memory-Engines von 17,0 GB (Milvus) bis zu 62,4 GB (Chroma), eine 3,7x-Spanne, oder 7,5 GB bis 27,7 GB pro Million Vektoren. Milvus bleibt am schlanksten, weil es den Index auf die Festplatte auslagert (DiskANN-Stil), während die reinen RAM-HNSW-Engines am schnellsten wachsen. So ist Milvus, das schwerste bei 50k (3.300 MB), das schlankste bei 2.25M (17,0 GB), während Chroma mit 62,4 GB das schwerste ist.

Die beiden On-Disk-Engines fallen aus diesem RAM-Vergleich heraus, da ihr Platzbedarf auf der Festplatte und nicht im RAM liegt. pgvector hat einen 18,4 GB großen On-Disk-Index und LanceDB einen 12,0 GB großen bei 2.25M, und ihr aktiver RAM ist ein Page-Cache über diesem Index und nicht das vollständige Working-Set, was nicht gemessen wurde. Eine Einschränkung gilt auch für die 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 Korpus aus Bulk-Load und Lesen. Reale RAG-Wissensdatenbanken fügen kontinuierlich Dokumente hinzu, aktualisieren und löschen sie, während der Index im Hintergrund zusammengeführt wird. Diese Churn-Workload wurde auf MedRAG-50k auf einer separaten 8-vCPU-Box ausgeführt, daher ist ihr Durchsatz intern für diesen Abschnitt und nicht mit den 32-Core-Geschwindigkeitszahlen vergleichbar. Die Korrektheitssignale (Recall- und Tombstone-Prüfungen) sind hardwareunabhängig.

Aktualität (Read-after-Write). Bei der Konsistenzeinstellung, mit der jede Engine konfiguriert war, ist jede 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 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 Growing Segments (der Vektor wird später in den persistenten HNSW-Graphen aufgenommen), sodass seine 12 ms die Durchsuchbarkeit des Growing Segments darstellen, ein gültiges benutzerseitiges Read-after-Write.

Schreib- und Lesevorgänge unter Mischlast. Mit einem Schreiber, der auf 150 Schreibvorgänge/s abzielt, und sechs Lesern, die 60 Sekunden lang abfragen, lag der Read-Recall bei jeder Engine zwischen 0,96 und 1,00, und kein Index degradierte unter gleichzeitigen Schreibvorgängen. Der einzeilige Schreibdurchsatz trennt die Engines um 57x, und die Reihenfolge ist nahe der Umkehrung des statischen Build-Rankings.

LanceDB zahlt einen Copy-on-Write-Commit pro Zeile und Chroma einen HTTP-Hinzufügen-Aufruf pro Zeile, weshalb die schnellsten statischen Ersteller unter Churn am langsamsten sind. Der Schreibdurchsatz hier ist die erreichte Rate gegen ein Ziel von 150/s unter gleichzeitigen Lesevorgängen, daher sind die schnellen Engines nahe bei 150 gedeckelt, anstatt ihre Spitzenwerte zu zeigen. Lesen Sie dies als einzeiliges, hochfrequentes Online-Schreibverhalten, nicht als Batch-Aufnahme, was der Design-Schwerpunkt dieser Engines ist und hier nicht getestet wurde.

Löschung und Kompaktierung. Beim Löschen eines zufälligen 20%-Anteils des Live-Sets und erneutem Einfü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-sekündiges VACUUM und Milvus eine 11-sekündige 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 führte diesen Abschnitt mit 3.000 anfänglichen Dokumenten statt 30.000 durch (seine synchrone Bulk-Aufnahme ist auf der kleinen Box langsam), sodass seine Read-QPS bei einem kleineren Korpus liegt. In diesem Maßstab 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 DB indiziert hat), den der approximative Index zurückgegeben hat. Er isoliert die Datenbank (Indextyp, ef/nprobe, Implementierung), nicht das Embedding.

nDCG@10 ist ein positionsgewichteter Score von 0 bis 1, der angibt, ob das vom Menschen als korrekt markierte Dokument nahe der Spitze der Ergebnisliste landet. Er misst die End-to-End-Abrufrelevanz, die größtenteils eine Eigenschaft des Embedding-Modells ist, das hier über alle Engines hinweg konstant gehalten wird.

Δ (Delta-Brücke) ist der nDCG@10 des Orakels abzüglich des nDCG@10 der Datenbank bei einer bestimmten Sucheinstellung. Es ü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 liegen bei der Abrufgenauigkeit 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-zu-Orakel-Brücke reicht von 0,009 (LanceDB) bis 0,023 (pgvector), sodass die Approximation der Datenbank höchstens 0,023 nDCG-Punkte Antwortqualität kostet.

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

Die Abrufzuverlässigkeit variiert stärker danach, was eine Anfrage fragt, als danach, welche Datenbank sie beantwortet. Über die 154 MedRAG-Anfragen beim exakten kNN-Orakel erzielen Faktoid-Lookups 0,888 nDCG@10, Bedingungsfragen 0,836, Vergleichsfragen 0,779 und Klausel-Existenz-Fragen 0,763. Die 0,125-Lücke zwischen Faktoid und Klausel-Existenz ist bei allen sieben Engines identisch vorhanden.

Metadatenfilter kosten Durchsatz, nicht Recall

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

Die Trennung liegt im Durchsatz. Chroma (11-19 QPS) und pgvector (10-56 QPS) halten den Recall bei 20 bis 40x niedrigerem gefilterten Durchsatz als der Rest. Milvus hält den höchsten Worst-Case-Recall (0,984) mit 268 bis 732 QPS über die Selektivität hinweg, während Redis bei niedriger Selektivität am schnellsten läuft (1.374 QPS bei 1%) mit einem niedrigeren Recall-Mindestwert (0,968). Bei 1-5% Selektivität ist ein Recall von 1,00 größtenteils der exakte Full-Scan-Zweig des Query-Planners unterhalb der Full-Scan-Schwelle jeder Engine, kein filterbarer HNSW, pro Engine offengelegt.

*LanceDBs gefilterter Recall wurde zuerst mit 0,24 bei geclusterten Filtern gemessen, dann zurückgezogen. Die Variation von ef wurde geändert, aber LanceDBs Recall-Stellschraube ist nprobes, daher lief es mit einem Standard von etwa 9% der Partitionen. Bei korrekten nprobes neu gemessen, erholt sich der geclusterte Recall@10 von 0,24 auf 0,76 (nprobes=128) bis etwa 1,00 (nprobes=256), bei 3 bis 5x niedrigerem QPS. LanceDB hält den gefilterten Recall, langsam. Eine recall-abgestimmte, gefilterte Durchsatz-Nachmessung 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-Schlüsselwort-Arms und dessen Verschmelzung mit dem dichten Arm durch reziproke Rang-Fusion (RRF, k=60) erhöht nDCG@10 um 0,030 bis 0,067 für jede Engine mit einem Schlüsselwort-Arm. Auf MedRAG sind der dichte und der BM25-Arm einzeln nahezu gleich stark (jeweils etwa 0,80), sodass die Erhöhung die Fehler beider Arme behebt, anstatt dass ein Arm dominiert.

Die Engines mit einem starken BM25-Arm profitieren am meisten, und pgvector und Weaviate profitieren weniger, entsprechend ihren schwächeren Schlüsselwort-Armen (0,740 und 0,782). Kein Hybrid einer Engine fällt unter seinen dichten Arm, sobald korrekt gemessen wird.

Was die Engines unterscheidet, ist native Fusion gegenüber clientseitigen Round-Trips, 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 keine serverseitige Fusion in dieser Version, sodass der Client zwei Round-Trips ausführt und in Python fusioniert. pgvector hat keine Fusion-API, fusioniert clientseitig, und sein Schlüsselwort-Arm ist Postgres ts_rank (Term Frequency mit Längennormalisierung, kein IDF), was mit einem OR-Volltextscan bei 12 QPS läuft. Self-hosted Chroma hat überhaupt keine rangierte Schlüsselwortsuche (BM25 ist eine Chroma-Cloud-Funktion), daher hat es keine Hybrid-Zeile.

Index-Erstellungszeit umfasst 13x

Bei 50k Vektoren reicht die Indexerstellung von 7 Sekunden (LanceDB) und 11 bis 13 (Weaviate, Milvus) bis zu 88 Sekunden (pgvector). Bei 2.25M erreicht die Spanne 13x. LanceDB und Milvus schließen in 7 bis 8 Minuten ab, gegenüber 44 Minuten für Redis und 92 für pgvector. Normalisiert auf die Box-Rate betragen die Erstellungskosten von €0,04 pro 1M Vektoren (LanceDB) und €0,05 (Milvus) bis €0,58 (pgvector). Die Erstellung ist ein einmaliger Kostenfaktor, der nur bei erneuter Indizierung des Korpus erneut anfällt.

Abrufqualität bei 2.25M Vektoren

Um die Qualität im großen Maßstab mit echten menschlichen Labels zu testen, haben wir einen 2.25M-Vektor-Korpus erstellt. Er kombiniert die 50k gelabelten MedRAG-Dokumente mit 2.2M Pubmed-Distraktoren, alle im selben bge-m3-Raum, integritätsgeprüft, sodass kein Distraktor ein falsch etikettiertes Ziel ist. Standard-ANN-Datensätze im Milliardenmaßstab tragen keine menschlichen Relevanz-Labels, sodass sie nicht zeigen können, was als Nächstes passiert.

Der geometrische ANN-Recall bleibt im großen Maßstab bestehen. Jede Engine erreicht immer noch Recall@10 über 0,973 bei 2.25M (Qdrant und Milvus bei 0,999), sodass der Index die wahren nächsten Vektoren findet. Die semantische Antwortqualität bleibt nicht erhalten. nDCG@10 fällt von etwa 0,81 bei 50k auf etwa 0,56 bei 2.25M für jede Engine, weil das korrekte Dokument unter 2.2M Distraktoren begraben ist.

Der Einbruch ist kein Datenbankeffekt. Er trifft das exakte kNN-Orakel identisch (Orakel-nDCG@10 bei 2.25M beträgt 0,572, und jede Engine befindet sich an dieser Obergrenze um 0,55 bis 0,57). Ob die Ursache die Obergrenze des Embeddings, die Korpusambiguität oder Single-Positive-Labels sind, die jetzt relevante Fast-Duplikate übersehen, wird hier nicht entschieden. Die Trennung dieser Ursachen erfordert eine menschliche Neubewertung der neu am höchsten eingestuften Dokumente. Die berichtbare Tatsache ist, dass die Skalierung des Korpus um 45x etwa ein Drittel der Antwortqualität (nDCG@10 0,81 auf 0,56) zunichte machte, während jeder ANN-Index einen nahezu perfekten Recall meldete, ein Effekt, den ein rein geometrischer Benchmark übersehen würde.

Haltbarkeit, HA und Sicherheit nach Engine

Geschwindigkeit, Speicher und Recall sind die gemessenen Achsen. Für einen Produktionseinsatz von RAG trennen die nicht gemessenen Achsen (Haltbarkeit, Hochverfügbarkeit, Zugriffskontrolle) diese Engines ebenfalls. Dieses Funktionsinventar basiert auf der offiziellen Dokumentation jeder Engine in der getesteten Open-Source-Version. Es ist ein Funktionsinventar, kein Chaos-Test. Tatsächliche Failover-Zeit, Datenverlustfenster bei der Wiederherstellung nach einem Absturz und 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 die Hochverfügbarkeit von Milvus im schwerfälligeren verteilten Modus lebt, nicht im hier gemessenen Standalone-Build. Keine der sieben verschlüsselt On-Disk-Daten nativ. Alle verlassen sich auf Festplatten- oder Volume-Verschlüsselung auf der Infrastrukturebene.

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

Wie approximative Nächste-Nachbarn-Suche funktioniert

Eine Vektordatenbank speichert einen hochdimensionalen Vektor pro Dokument und gibt bei einem Abfragevektor die k nächsten nach einer Distanzmetrik zurück (hier Kosinus über L2-normalisierten Vektoren). Die exakte Nächste-Nachbarn-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, um damit zu arbeiten.

Approximative Nächste-Nachbarn-Indizes (ANN) geben etwas Genauigkeit auf, um nur einen Bruchteil der gespeicherten Vektoren zu durchsuchen. Die dominierende Struktur unter diesen Engines ist HNSW, ein geschichteter Proximity-Graph, der von einem groben Einstiegspunkt zu einer dichten Nachbarschaft hinabsteigt und dabei eine begrenzte Anzahl von Kandidaten besucht, die durch eine Such-Stellschraube (ef für HNSW, nprobe für IVF) festgelegt wird. Ein größerer ef-Wert besucht mehr Kandidaten, erhöht den Recall und senkt die QPS. Ein kleinerer ef-Wert bewirkt das Gegenteil.

Da diese Stellschraube kontinuierlich Recall gegen Geschwindigkeit tauscht, 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 variiert die Stellschraube, zeichnet die Recall-gegen-QPS-Kurve jeder Engine auf und liest sie alle bei demselben Recall. Dieser recall-abgestimmte Punkt (hier Recall@10 = 0,95) ist derjenige, an dem die QPS-, Latenz- und Speicherwerte in diesem Benchmark gemessen 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 oder Append-Only-File).

Hardware. Eine Hetzner CCX53 (32 dedizierte vCPUs, 128 GB RAM, NVMe, nbg1) für Genauigkeit, Geschwindigkeit, Speicher, Filterung und Erstellung, jeweils ein Container aktiv, ein frischer Container pro Index-Build und ein colozierter 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. Anfragen tragen Single-Positive-Human-Labels (target_doc_id).

Korpora. MedRAG-50k (154 Anfragen) und TechQA-28k (151 Anfragen) für die Abrufqualität, und ein 2.25M-Vektor-Korpus (50k gelabelt plus 2.2M Distraktoren) für die Skalierungsstufe. Die Hybrid-Dimension wurde auf lokalem Docker erneut ausgeführt, daher sind ihre QPS unter den Hybrid-Zeilen vergleichbar, nicht mit den Box-Zahlen. Ihr nDCG und Δ sind hardwareunabhängig.

Statistik. 100+ Durchläufe pro Messung, IQR-Ausreißerbereinigung bei 3,0x, perf_counter_ns-Timing. Anfrage-Pools von 154 bis 246 begrenzen die Tail-Berichterstattung auf p95, gelegentlich p99. p99.9 ist bei diesen Anzahlen undefiniert.

Doppelte 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 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 in Geschwindigkeit und Speicher bei abgestimmtem ANN-Recall, und die Δ-Brücke übersetzt ihren Approximationsverlust in Antwortqualität.

Korrektheitsanker. Jedes enginespezifische Rezept (Filter und Hybrid) wurde der offiziellen Dokumentation der exakten Version entnommen und vor der Codierung gegnerisch verifiziert. Die Hybrid-Dimension trägt einen unabhängigen BM25-Antwortschlüssel (zwei Referenzen stimmen bei nDCG etwa 0,81 überein), sodass eine Engine, die weit davon abweicht, auf einen Fehler im Test-Harness hinweist, nicht auf ein Ergebnis. Diese Sicherung kennzeichnete drei Messfehler im ersten Durchlauf, 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 durch erneutes Messen aller sieben Engines in einer konsistenten Umgebung behoben, 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 keine gemeldete Zahl zwar schnell, aber falsch ist.

Statistische Signifikanz

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

Die Hybrid-Erhöhung ist der knappe Fall, daher sind ihre Intervalle das entscheidende Beweismittel. Vier Engines liegen klar über null, zwei nicht:

Die Abrufgenauigkeit ist dieselbe Regel, andersherum gelesen. Der nDCG@10 der sieben Engines liegt innerhalb sich überschneidender Intervalle über eine Spanne von 0,014, also gewinnt keine, was das Unentschieden bedeutet. Die Reihenfolge nach Geschwindigkeit und Speicher liegt weit außerhalb dieser Unsicherheit, mit Lücken (10x Single-Thread-Durchsatz, 3,7x Spitzenspeicher), die das Bootstrap-Rauschen in den Schatten stellen.

Getestete Engines

Einschränkungen

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

Menschliche Labels sind Single-Positive (ein korrektes Dokument pro Anfrage), ohne abgestufte Relevanz oder Übereinstimmung zwischen Annotatoren, sodass nDCG@10, MRR@10 und Hit@10 bei 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 Abrufschicht. Die Stufen des Rerankers (Cross-Encoder) und der LLM-Antwortgenerierung einer RAG-Pipeline liegen außerhalb des Umfangs. Verwaltete Cloud-Engines (Pinecone, Zilliz und andere) sind eine spätere Phase. Der Haltbarkeits- und Sicherheitsvergleich basiert auf Dokumenten, ist nicht chaos-getestet.

Weiterführende Literatur

• Embedding-Modelle Benchmark
• Reranker Benchmark
• Vektordatenbank-Rechner
• Quelloffene Embedding-Modelle
• Mehrsprachige Embedding-Modelle
• Multimodale Embeddings
• Agentische RAG Frameworks

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

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