Vergleich von fünf eingebetteten Vektorlagern: FAISS, Chroma, LanceDB, VectLite

Die meisten Vergleiche der „besten Vektordatenbanken“ lesen sich wie umformulierte Landing Pages der Anbieter selbst: Pinecone ist schnell, Qdrant zuverlässig, Chroma einfach – alle gewinnen. Dieser Vergleich geht von einem engeren Anwendungsbedarf aus. Kein Cluster, kein Docker, keine offenen Ports, kein verwalteter Plan. Einfach nur ein eingebetteter Vektor-Speicher, der aus einer einzigen lokalen Datei, einem pip install und drei Zeilen Python besteht. Hier ist daher ein selbst erstellter Benchmark von fünf Engines für genau diesen Zweck.

Die Zahlen

Das Datensatz enthielt 5.000 Vektoren mit 384 Dimensionen, die 50 Mal mit der Kosinusähnlichkeit abgefragt wurden. Alles wurde unter macOS (x86_64) mit Python 3.12.8 unter Verwendung der Standardeinstellungen jeder Engine ausgeführt.

In zehn Sekunden: FAISS ist am schnellsten, obwohl es kaum als Datenbank gilt. Chroma eignet sich am besten zum Einstieg, doch sein Standard-Rückrufwert von 84 % ist ein Problem, das viele Menschen stillschweigend ignorieren. VectLite erreicht im eingebetteten Modus ohne Anpassungen einen Rückrufwert von 96,6 %, was eine Überraschung war. LanceDB strebt einen perfekten Rückrufwert an, was sich in einer höheren Latenz bemerkbar macht. NumPy dient lediglich als Vergleichsmaßstab und ist kein echter Konkurrent.

Warum „schnellstes“ die falsche Bewertung ist

Der Markt für Vektor-Datenbanken ist ein Wettstreit im Marketing. Jeder Anbieter veröffentlicht einen Benchmark, den er zufällig gewinnt, Vergleichsartikel wiederholen die Zahlen ohne Kontext, und alle konzentrieren sich auf die Latenz. Allein die Latenz irreführt. Mit halbem Millisekunde Antwortzeit, aber falschen Ergebnissen, ist es schlimmer, als 5 ms zu benötigen, um die richtigen Ergebnisse zurückzugeben. Das misst die Trefferquote, und deshalb zeigen seriöse Tools wie ANN-Benchmarks (https://ann-benchmarks.com/) die Trefferquote im Verhältnis zur Durchsatzrate an.

Diese Testreihe misst daher beides gleichzeitig: Einerseits die Latenzwerte p50, p95 und p99 sowie die Anzahl der Abfragen pro Sekunde, andererseits die Trefferquote@10 im Vergleich zu einer präzisen Kosinus-Suche mit reinem NumPy.

Was getestet wurde und was nicht

Das Projekt ist ein kleines Python-Paket namens vectlite-benchmark-lab. Jeder Engine implementiert eine gemeinsame VectorStore-Schnittstelle, und der Runner ruft sie nacheinander auf. Es umfasst:

• Batch-Eingabe
• k-NN-Suche mit Messung der Trefferquote
• Filtern von Metadaten nach exakter Übereinstimmung anhand eines tenant_id
• Zeit zum Starten nach dem ersten Mal
• Backups und Portabilität
• Exporte in CSV-, JSON-Format sowie Matplotlib-Diagramme

Und was es nicht beinhaltet – das wird von vornherein klar gesagt: keine verteilte oder mehrknotige Konfiguration, keine mehr als 5.000 Vektoren in dieser Runde, keinerlei Anpassungen des Indexes sowie weder Qdrant noch pgvector, da diese einen laufenden Server benötigen, während das Ziel ein rein lokaler Betrieb war. Diese letzte Entscheidung ist bewusst getroffen worden. Die erste wichtige Frage lautet nicht, wer nach zwei Wochen an Anpassungen gewinnt, sondern wie sich eine Engine verhält, wenn man sie installiert und nichts weiter ändert.

Methodik

Die Ground Truth ist eine brute-force-Kosinus-Suche in NumPy. Die Recall-Rate eines Engines ist der Anteil an echten Nachbarn, die er zurückgibt, aufgeschlüsselt nach den einzelnen Abfragen. Konfiguration für den Ausführungsvorgang:

vectlite      : 0.10.0
vectors       : 5,000 (synthetic, normalized)
dimensions    : 384
queries       : 50
top_k         : 10
metric        : cosine
filter        : tenant_id (exact-match)
warmup        : 5 queries discarded
hardware      : macOS x86_64, Python 3.12.8

Um es auf Ihrem Rechner nachzuvollziehen, führen Sie den vollständigen Befehl aus:

PYTHONPATH=src python -m vectlite_benchmark_lab run \
  --stores vectlite,faiss,chroma,lancedb,numpy_exact \
  --vectors 5000 --dimensions 384 --queries 50 \
  --top-k 10 --batch-size 500 \
  --output-dir results/vectlite-0.10.0 \
  --data-dir data/vectlite-0.10.0

Vergleichen Sie anschließend Ihre Ergebnisse mit diesen und betrachten Sie die Unterschiede.

FAISS: die Geschwindigkeitsgrenze

FAISS gewinnt in jeder Spalte bezüglich der Latenz: 0,65 ms p95 bei perfekter Trefferquote – das ist ungefähr das, was man von einer seit einem Jahrzehnt dafür optimierten C++-Bibliothek erwarten würde. Doch es handelt sich dabei nicht um eine Datenbank. Es gibt kein natives Filtern von Metadaten, keine eingebauten Persistenzfunktionen und keine portablen Backups. Man kann es in eine Schicht einbetten, die diese Funktionen hinzufügt, und das wird tatsächlich getan, doch aus der Box heraus ähnelt es eher einer Mathematikbibliothek als etwas, das man Kunden zur Verfügung stellen würde. Der Vergleich mit Chroma ist wie der Vergleich eines F1-Motors mit einem Toyota: Der eine ist auf der Rennstrecke schneller, der andere bringt den Einkauf nach Hause. Es bleibt als Referenz in der Tabelle. Wenn man nur eine reine Vektorabfrage benötigt, ist es die offensichtliche Wahl.

Chroma: einfacher Einstieg – achten Sie auf die Trefferquote

Chroma ist die Standardwahl für RAG-Prototypen – und die Entwicklererfahrung rechtfertigt das. Installieren Sie chromadb, schreiben Sie fünf Zeilen, und schon werden die Dokumente indiziert.

Das Problem ist die Rückrufrate. Mit diesen Daten ohne angewendete Filter findet Chroma nur 84 % der tatsächlichen relevanten Ergebnisse, was bedeutet, dass etwa jedes sechste erwartete Ergebnis ausbleibt. Für einen Prototypen ist das in Ordnung. In einem produktiven RAG-System, bei dem die Qualität der Ergebnissuche die Antwort des Modells bestimmt, handelt es sich um einen stillen Verlust an Relevanz, den die API nicht offenbart. Durch Anpassung der HNSW-Einstellungen lässt sich der größte Teil dieses Defizits ausgleichen – vorausgesetzt, man weiß, dass dies notwendig ist. Mit Filtern beträgt die Rückrufrate 100 %, doch die p95-Latenz steigt auf 18,76 ms, was deutlich langsamer ist als bei den anderen Methoden für dieselbe Aufgabe. Fazit: Am ersten Tag hervorragend und auch nach dreißig Tagen noch gut – vorausgesetzt, man passt die Einstellungen vor der Produktion an.

VectLite: die Überraschung

Die Version 0.10.0 erreicht bei den Standardeinstellungen eine Trefferquote von 96,6 %, die höchste unter allen hier vorhandenen eingebetteten Engines. Die Suche ohne Filter benötigt 5,71 ms, was im Durchschnitt liegt (Chroma 3,14, LanceDB 12,20). Bei gefilterten Daten dauert sie 10,28 ms, während Chroma 18,76 ms benötigt – also fast doppelt so schnell.

Der Fortschritt seit den ersten Veröffentlichungen ist sichtbar. Im Vergleich zu v0,1.x stieg die Datenaufnahmerate von 47 auf 154 Vektoren pro Sekunde (etwa 3,3-mal schneller), die Trefferquote erhöhte sich von 0,948 auf 0,966 und die Suchzeit ohne Filter sank von 18,6 ms auf 10,3 ms, was einem Rückgang von 45 % entspricht.

Die Datenaufnahme ist der Schwachpunkt. 154 Vektoren pro Sekunde sind im Vergleich zu Chromas 2.000 und mehr sowie zu LanceDB sehr langsam. Bei einigen tausend einmal indizierten Dokumenten spielt das keine Rolle. Bei einer Million Vektoren bedeutet das jedoch einen langen Wartezeitraum – daher ist dies vermutlich das Nächste, was behoben werden muss. Dennoch war dies der einzige Engine in der Gruppe, deren Leistungsdaten keine Rechtfertigung benötigten.

LanceDB: perfekte Trefferquote, langsamere Suche

LanceDB erreicht eine 100%-ige Trefferquote und verarbeitet 20.120 Vektoren pro Sekunde – auf dem Papier beeindruckend. Der Nachteil ist die Suchverzögerung: 12,20 ms p95, was das Langsamste unter den fünf ist. Für einen Batch-Prozess, bei dem Tausende von Abfragen über Nacht verarbeitet werden, spielt das keine Rolle. Für ein interaktives Tool, bei dem jemand am Keyboard wartet, summieren sich diese Verzögerungen jedoch. Gut geeignet für Batch- und Analyseanwendungen, etwas langsam für interaktiven Gebrauch.

NumPy: der Schiedsrichter

Die brute-force-basierte Kosinus-Suche über die gesamte Matrix garantiert per Definition eine perfekte Trefferquote, wobei die Verzögerung bei einigen Zehntausend Vektoren noch akzeptabel ist, danach jedoch drastisch ansteigt. Es handelt sich dabei nicht um ein Produkt, sondern um den Maßstab, anhand dessen alle anderen Engines bewertet werden.

Welchen soll man wählen?

Der Benchmark krönt keinen Sieger – er zeigt vielmehr die Abwägungen auf. Eine grobe Zuordnung nach Anwendungsfall:

• Schnelles RAG-Prototyp: Chroma – dank einer zweiminütigen Einrichtung und einem umfangreichen Ökosystem
• Embedded-AI-Speicher: VectLite – für die beste Standard-Rückrufleistung sowie eine tragbare Datei
• Lokaler Batch-Pipeline: LanceDB – für eine perfekte Rückrufleistung und schnelle Einpflegung
• Reine ANN ohne Filterung: FAISS – für uneinholbare Latenzzeiten
• Verteilte Produktion: Qdrant oder Milvus – eine andere Kategorie, die hier nicht getestet wurde

Kalte Startzeit und Backup

Zwei Messwerte, die die meisten Benchmarks überspringen. Startzeit, also die Zeit, bis die Datenbank nach einem Neustart wieder geöffnet werden kann: FAISS benötigt 0,001 ms, LanceDB 2 ms, Chroma 5 ms und VectLite 3.059 ms. VectLite zahlt bei der Wiederöffnung einen hohen Preis. Das spielt für einen langlaufenden Prozess keine Rolle, doch für eine serverlose Funktion oder ein CLI-Tool, das auf Anfrage gestartet wird, ist eine dreisekündige kalte Startzeit schwer verkaufbar und wahrscheinlich das Erste, was behoben werden muss.

Backup: VectLite erzeugt ein 19 MB großes, tragbares Artefakt in 54 ms. Das Kopieren, Versionieren und Bereitstellen erfolgt wie bei herkömmlichen Dateien. Genau diese Eigenschaft, die als „eingebettet“ bezeichnet wird, sorgt für die Funktionalität – dieselbe Eigenschaft, die SQLite zwei Jahrzehnte lang am Leben hielt.

Beschränkungen dieses Tests

Jeder Benchmark benötigt einen Hinweis auf mögliche Einschränkungen. Hier sind fünf davon:

1. 5.000 Vektoren sind eine geringe Anzahl; das Verhalten ändert sich bereits bei 100.000 und mehr Vektoren.
2. Nur die Standardeinstellungen wurden verwendet; Chroma und VectLite lassen sich mit hoher Wahrscheinlichkeit weiter optimieren.
3. Keine Server-Engine wurde eingesetzt: Qdrant, Milvus, Weaviate und pgvector fallen somit aus.
4. Es handelt sich um einen einzigen Testlauf ohne Konfidenzintervalle und ohne Wiederholungen.
5. Der Test wurde auf einem einzigen Rechner durchgeführt, daher können andere Hardware-Konfigurationen andere Ergebnisse liefern.

Der Code ist open source und die Ergebnisse sind reproduzierbar, wodurch ein festgestellter Bias oder Fehler unbedingt gemeldet werden sollte.

Nächste Schritte und Erkenntnisse

Diese Auswertung dient als Ausgangspunkt, nicht als endgültiges Urteil. Die kurze Liste für die nächste Runde umfasst: einen 100k-Vektor sowie eine 768-dimensionalige Auswertung aller Engines; einen RAG-stiligen Test mit einem Markdown- und PDF-Korpus sowie von Menschen verfassten Abfragen; angepasste Recall-Werte, sodass die Engines bei vergleichbarer Präzision gegeneinander antreten; einen kürzeren VectLite-Kaltstart; sowie wiederholte Auswertungen mit Konfidenzintervallen.

Die Suche nach „der besten Vektordatenbank“ endet ohne eine universelle Antwort, da sie davon abhängt, wie man Relevanz gegenüber Latenz, Eingabe und Startzeit abwägt. Es gab keinen überlegenen Spitzenreiter, sondern jede Engine hat ihre eigene Besonderheit. FAISS ist eine Geschwindigkeitsreferenz, die sich als Datenbank ausgibt. Chroma ist ein einfacher Einstieg, der vor der Produktion noch angepasst werden muss. LanceDB ist der Perfektionist, dem Langsamkeit nichts ausmacht. NumPy ist der unparteiische Richter, der sich nicht skalieren lässt. VectLite hingegen erreicht schweigend das Ziel der Relevanz ohne Kompromisse.

Für einen lokalen Agenten, ein CLI-Tool oder ein offline-first RAG auf einem Laptop bietet VectLite überzeugende Vorteile: SQLite machte lokale relationale Daten langweilig und portabel, und VectLite strebt dieselbe Rolle mit KI-gestützter Speicherung an. Das bedeutet in diesem Fall eine 19 MB große Datei, die in etwa 6 ms antwortet.

Referenzlinks: ANN-Benchmarks unter https://ann-benchmarks.com/, Qdrant’s Benchmark-Hinweise unter https://qdrant.tech/benchmarks/, FAISS unter https://github.com/facebookresearch/faiss, Chroma-Dokumentation unter https://docs.trychroma.com/ sowie LanceDB unter https://lancedb.github.io/lancedb/.