LanceDB lud 100.000 OpenAI-Embeddings 22-mal schneller als pgvector, während pgvector dieselbe Arbeitslast von acht gleichzeitigen Clients 1,8-mal schneller bewältigte. Auch der Abstand bei der Single-Thread-Latenz und der Speichereffizienz ging zugunsten von LanceDB aus, was Entwicklern eine datengestützte Entscheidungsgrundlage für die Wahl eines Vector Stores bietet.

Warum ein Benchmark jetzt wichtig ist

Die Vektorsuche hat den Sprung von Forschungslaboren hin zu Produktionsdiensten wie Empfehlungsmaschinen und Retrieval-Augmented Generation (RAG) geschafft. Die meisten Teams nutzen bereits PostgreSQL, weshalb die pgvector-Erweiterung eine Ähnlichkeitssuche ohne neue Infrastruktur verspricht. Spezialisierte Stores wie LanceDB beanspruchen hingegen eine geringere Latenz und kostengünstigeren Speicher. Teams müssen zwischen „es zu dem hinzufügen, was wir bereits haben“ und „eine zweckgebundene Engine betreiben“ wählen – eine Entscheidung, die sich auf Kosten und Leistung auswirkt, wenn Datensätze wachsen und die Anfrageraten steigen.

Aufbau des Tests

Beide Systeme indizierten dieselben 100.000 Vektoren mit jeweils 1.536 Dimensionen, die von OpenAIs Embedding-Modell generiert wurden. Wir haben die Ingestionsgeschwindigkeit, die Festplattennutzung, die Single-Thread-Abfragelatenz und den Durchsatz mit acht gleichzeitigen Clients gemessen.

Direkter Vergleich der Ergebnisse

  • Ingestionsgeschwindigkeit – LanceDB verzeichnete einen 22-fachen Vorteil.
  • Speicherplatzbedarf – LanceDB speicherte die Vektoren in etwa einem Drittel des von pgvector genutzten Platzes.
  • Single-Thread-Latenz – Abfragen liefen auf LanceDB etwa doppelt so schnell.
  • Skalierung bei Nebenläufigkeit – Mit acht parallelen Clients lieferte pgvector einen 1,8-mal höheren Durchsatz als LanceDB.

Architektonische Ursachen der Unterschiede

LanceDB ist eine Embedded-Library, die innerhalb des Python-Prozesses läuft, der die Anwendung hostet. Alle Operationen bleiben im Prozess, sodass Daten niemals eine Netzwerk-Grenze überschreiten und der Index mit minimalem Overhead aktualisiert wird. Dieses Design glänzt bei Single-Task-Workloads, stößt jedoch an Grenzen, wenn mehrere Python-Threads um den Global Interpreter Lock (GIL) konkurrieren, der eine echte parallele Ausführung von Python-Bytecode verhindert.

pgvector erweitert PostgreSQL auf der Serverseite. Jede Client-Verbindung startet einen separaten Serverprozess und umgeht so den GIL vollständig. Der PostgreSQL-Planner entscheidet, wie eine Ähnlichkeitssuche erfüllt wird, und der Server kann viele Prozesse starten, um gleichzeitige Anfragen zu bedienen. Diese Isolation erklärt die bessere Skalierung unter Last.

Besonderheiten bei Filterung und Query-Planung

RAG-Pipelines in der Praxis kombinieren oft Vektorsimilarität mit traditionellen Filtern (z. B. WHERE user_id = 42). LanceDB wendet einen Prefilter an, der bei jedem Durchlauf vorhersehbar reagiert. pgvector verlässt sich auf den Query-Planner von PostgreSQL, der je nach Statistiken entweder einen schnellen Index-Scan wählen oder auf einen langsameren Exact-Scan zurückgreifen kann. Das Ausführen von ANALYZE nach dem Bulk-Loading einer pgvector-Tabelle aktualisiert diese Statistiken; ohne diesen Schritt kann der Recall auf nahezu Null sinken, was die Suche effektiv unbrauchbar macht.

Wann welche Option sinnvoll ist

Wählen Sie pgvector, wenn

  • Ihr Stack bereits PostgreSQL enthält und Sie vermeiden möchten, einen weiteren Dienst hinzuzufügen.
  • Sie viele gleichzeitige Nutzer oder API-Aufrufe erwarten.
  • ACID-Garantien und vertraute DBA-Tools wichtig sind.

Wählen Sie LanceDB, wenn

  • Ihr Workflow eine ML-Pipeline ist, die häufig neue Embeddings aufnimmt.
  • Sie den schnellsten Schreibpfad und eine geringe Latenz für Single-Request-Agenten (z. B. Chatbots) benötigen.
  • Die Speicherkosten ein Thema sind und Sie die Obergrenze der Single-Thread-Performance tolerieren können.

Fazit: Wenn reine Ingestionsgeschwindigkeit, minimaler Speicherbedarf und Single-Request-Latenz am wichtigsten sind, gewinnt LanceDB. Wenn Sie viele Nutzer gleichzeitig bedienen müssen und auf eine bestehende PostgreSQL-Installation angewiesen sind, ist pgvector aufgrund seines Vorteils bei der Nebenläufigkeit die sicherere Wahl. Nutzen Sie die Zahlen aus diesem Benchmark, um den Vector Store auf die kritischste Metrik Ihres Produkts abzustimmen.