LanceDB: Vektorsuche, die als Bibliothek beginnt

LanceDB ist eine eingebettete Vektordatenbank: eine Rust-Bibliothek, die sich in den Anwendungsprozess einlinkt und Vektoren, Metadaten und Quelltext im Spaltenformat Lance speichert. Kein Server zum Deployen, kein Cluster zum Ausdimensionieren, kein Connection-Pool zum Tunen — das stärkste Argument dafür und der Grund, es eher mit SQLite als mit Qdrant zu vergleichen.

Es konkurriert mit den eingebetteten Optionen — SQLite mit einer Vektor-Erweiterung, Chroma, ein In-Process-Index — und, auf Object Storage gezeigt, mit den gehosteten Diensten. Es ersetzt das Muster, für ein Korpus, das auf eine Maschine passt, einen eigenen Suchcluster zu betreiben.

Was LanceDB ist

Die aktuelle Version ist 0.40.0, veröffentlicht am 7. Oktober 2026 und Python 3.10 oder neuer voraussetzend, mit JavaScript- und Rust-Clients auf demselben Rust-Kern. Die Daten liegen dort, wo die Verbindungs-URI zeigt: ein lokales Verzeichnis, s3://, gs://, az:// oder db:// für den Enterprise-Cluster — und dieselben Lance-Dateien liest beide Editionen.

• Lizenz: Apache-2.0 für die Bibliothek; Enterprise ist ein kommerzielles Produkt als Managed oder Bring-Your-Own-Cloud.
• Gestalt: eingebettet im eigenen Prozess — kein Daemon, kein Sharding, keine eigene Abfragesprache.
• Speicher: das Lance-Format hält Vektoren, Metadaten und Rohdaten in einer Tabelle, mit Versionierung und Zero-Copy-Lesern über Apache Arrow.
• Indizes: IVF_RQ, IVF_PQ, IVF_HNSW_SQ und IVF_HNSW_FLAT für Vektoren, BM25 für Volltext, dazu Skalarindizes.
• Suche: Vektor-, Volltext- und Hybridabfragen mit Reranking, standardmäßigem Prefilter, Distanzgrenzen und einem exakten Scan als Ausweg.
• Skalierung: bequem auf einem einzelnen Knoten; die FAQ nennt etwa 10 bis 50 Milliarden Zeilen und 10 bis 30 TB, bevor Enterprise die Antwort ist.
• Clients: Python, JavaScript und Rust, installiert per pip, npm oder cargo.

Wie eine Abfrage läuft

Eine Suche ohne Index ist ein Scan: jeder Vektor wird mit der Abfrage verglichen und die nächsten k zurückgegeben — exakt und schnell genug, solange die Tabelle klein ist. Ein IVF-Index investiert Trainingszeit, um Vektoren in Partitionen zu clustern, daher vergleicht die Abfrage zuerst mit wenigen Zentroiden und rechnet dann in diesen Partitionen per Brute Force; nprobes, standardmäßig 20, legt fest, wie viele Partitionen geöffnet werden. HNSW sitzt danach in jeder Partition als Graph der zweiten Ebene — deshalb sagt die Dokumentation, HNSW sei in LanceDB kein Index der obersten Ebene.

Die Volltextsuche ist ein eigener BM25-Index, gebaut mit create_fts_index, und die Hybridsuche führt beide Hälften aus und verschmilzt sie: standardmäßig mit einem RRF-Reranker, der jede Liste in Ränge übersetzt und addiert, sodass ein Ergebnis gewinnt, das in beiden Hälften gut rangiert, ohne dass eine der beiden Skalen dominiert. Filter in where sind standardmäßig Prefilter, angewandt vor der Bewertung; prefilter=False verschiebt den Filter hinter die Teilabfragen, die dann weniger als limit Zeilen liefern können.

Die Speicherschicht bestimmt das Latenzprofil. Auf lokaler Platte sind Lesezugriffe speichergemapped und schnell; auf S3, GCS oder Azure Blob ist jeder kalte Lesen ein Netzwerk-Roundtrip, und der eigene Vergleich des Herstellers nennt dafür 500 bis 1.000 ms bei der Open-Source-Edition gegen 50 bis 200 ms bei Enterprise, wo ein NVMe-Cache die Wiederholungslesezugriffe auffängt.

Welchen Index man baut

Die Indexwahl ist zuerst eine Kompressionsentscheidung, und die Dokumentation sagt den Trade-off ungeschönt:

Zwei Regeln aus der Doku zählen mehr als die Tabelle. HNSW erscheint nie allein: es ist immer nur eine Unterstruktur innerhalb von IVF-Partitionen, es gibt also keinen schlichten HNSW-Index zu erstellen. Und wenn die Last Metadatenfilter enthält, empfiehlt die Doku IVF_RQ oder IVF_PQ, weil die HNSW-Varianten bei gefilterter Suche eine höhere Latenzvarianz zeigen.

Erste Schritte

Paket installieren, auf ein Verzeichnis zeigen, und die Tabelle liegt auf der Platte. Der folgende Ausschnitt baut beide Indizes und führt die Hybridsuche aus, wie die Dokumentation sie empfiehlt, mit angewandtem Metadatenfilter vor der Bewertung.

import lancedb
from lancedb.rerankers import RRFReranker

db = lancedb.connect("./data")            # a local directory, no server
table = db.open_table("documents")
table.create_fts_index("text")            # BM25, built in the background

results = (
    table.search(query_type="hybrid")
    .vector(embed(query))                 # your embedding model
    .text("refunds within 14 days")
    .where("lang = 'en'", prefilter=True)  # default: filter before scoring
    .rerank(RRFReranker())                # the default hybrid reranker
    .limit(5)
    .to_list()
)
for row in results:
    print(round(row["_relevance_score"], 3), row["text"][:80])

In diesem Ausschnitt braucht weder ein Server noch ein Container noch einen API-Schlüssel, und derselbe Code läuft gegen s3://, sobald sich die Verbindungs-URI ändert. Volltext- und Vektor-Indexbauten kehren sofort zurück und laufen im Hintergrund; wait_for_index zusammen mit index_stats ist die Art, wie ein Job prüft, dass nichts mehr außerhalb des Index liegt.

Wo es hakt

Die Schwächen folgen aus der Architektur. Ein Prozess bedeutet ein Host: der eigene Vergleich des Herstellers deckt die Open-Source-Edition bei 10 bis 50 Abfragen pro Sekunde ohne Cache ab, und jede Wartungsaufgabe — Kompaktierung, Reindexierung, Indexfragmentierung nach Löschungen — ist ein Job, den jemand einplanen muss. Gleichzeitige Schreibvorgänge sind durch die Anzahl der Commit-Wiederholungen begrenzt, und Python-Anwender werden gewarnt, nicht zu forken.

Das ehrliche Fazit: LanceDB ist am billigsten zu betreiben und am aufwendigsten zu warten. Die Tabelle des Herstellers nennt für einen Prozess 10 bis 50 Abfragen pro Sekunde und 500 bis 1.000 ms auf Object Storage, wobei verteilte Suche und plattformgesteuerte Kompaktierung auf der Enterprise-Seite weiterhin als kommend markiert sind — wissenswert, bevor eine Kaufentscheidung auf der Roadmap ruht.

Die API-Asymmetrie ist der andere Störfall: Auf einer Enterprise-RemoteTable werden die Tabellenmethoden to_arrow und to_pandas abgelehnt, die Materialisierung muss also über den Query-Builder laufen, und ein Vorgang kann an einer Service-Richtlinie scheitern statt an den Daten. Der Code von OSS nach Enterprise ist nahezu derselbe, aber nicht derselbe.

Preise

Die Bibliothek ist Apache-2.0 und in jedem relevanten Sinne kostenlos: pip install, kein Konto, kein Metering. Die Preisseite führt keine Preisliste — sie ist ein Kontaktformular —, und Enterprise wird als Managed oder Bring-Your-Own-Cloud mit SOC 2 Type II, HIPAA-Abdeckung und OpenTelemetry-Metriken und Traces verkauft. Die eine konkrete Zahl, die der Hersteller veröffentlicht, ist ein Benchmark von etwa 779 Dollar im Monat für 100 Millionen Vektoren.

• Open Source: Bibliothek, Indize, Hybridsuche und die Wartungs-CLI unter Apache-2.0, mit Community-Support.
• Enterprise: Managed oder BYOC, verteilte Query-Knoten, ein NVMe-Cache, plattformgesteuerte Indexierung und Kompaktierung sowie Compliance nach SOC 2 Type II und HIPAA.
• Als Nächstes, in der eigenen Tabelle des Herstellers: verteilte Suche, verteilte Indexierung und Kompaktierung.

Fazit

LanceDB ist die richtige Antwort, wenn Korpus und Traffic auf eine Maschine passen, und die falsche, wenn nicht — das sagt der Hersteller in seiner eigenen Vergleichstabelle. Seine Stärke ist, dass Retrieval zum Bibliotheksaufruf wird statt zu einem Infrastrukturprojekt; seine Kosten liegen darin, dass jede betriebliche Aufgabe einer Datenbank beim Anwendungsteam landet. Die pointierte Lesart: Für eine RAG-Pipeline unter einer Million Chunks ist eine eigene Vektordatenbank ein unnötiger Dienst, und LanceDB ist das, worauf diese Pipeline zuerst zugreifen sollte.

1. Für Prototypen, eine Single-Node-RAG-Pipeline oder Edge-Deployment nutzen, wo ein Datenbankserver die schwerste Komponente im Stack wäre.
2. Nutzen, wenn die Daten bereits im Object Storage liegen und Versionierung sowie Zero-Copy-Lesen des Lance-Formats eine zweite Kopie des Korpus ersparen.
3. Zweimal nachdenken, wenn Abfragen aus S3 unter 100 ms bei echter Konkurrenz bleiben müssen — die eigene Zahl des Herstellers für OSS liegt bei 500 bis 1.000 ms und 10 bis 50 Abfragen pro Sekunde.
4. Wartung einplanen: optimize, Kompaktierung und Reindexierung sind in der Open-Source-Edition ungeplante Arbeit, und Indexfragmentierung wächst mit jedem Delete.
5. Die Enterprise-Stufe nur für die verteilten Teile wählen; die API-Unterschiede, von den Materialisierungs-Grenzen der RemoteTable bis zu Guardrails auf Clusterseite, das ist die eigentliche Bindung.

Quellen

1. LanceDB-Quickstart
2. LanceDB-Vektorindizes
3. LanceDB-Indexierungsleitfaden
4. LanceDB-Hybridsuche
5. LanceDB Enterprise
6. LanceDB-Häufige Fragen
7. LanceDB-Preise
8. LanceDB auf PyPI