> Ein Test von LanceDB: eine Apache-2.0-Bibliothek statt Server, die IVF- und HNSW-Indexwahl, Hybridsuche mit Rangfusion und was Enterprise zusätzlich bringt.
>
> Web page: https://balazscsorba.com/de/blog/lancedb · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/lancedb.md) · [Magyar](https://balazscsorba.com/hu/blog/lancedb.md)
> Author: Balázs Csorba · Published: 2026-09-21 · Keywords: lancedb, lancedb review, lance vector database, embedded vector database, lancedb vs qdrant, hybrid search rrf, lancedb indexing, lance data format

[Blog](https://balazscsorba.com/de/blog)/Retrieval & Suche

# LanceDB: Vektorsuche, die als Bibliothek beginnt

Ein Test von LanceDB: eine Apache-2.0-Bibliothek statt Server, die IVF- und HNSW-Indexwahl, Hybridsuche mit Rangfusion und was Enterprise zusätzlich bringt.

[Balázs Csorba](https://balazscsorba.com/de/about)·21\. September 2026·9 Min. Lesezeit

-   Vector search
-   Hybrid search
-   Embedded database
-   RAG

![Eine verschachtelte Kiste mit drei Blättern, zwei Pfeile vereinen sich aus quadratischem und rundem Tablett.](https://balazscsorba.com/images/blog/lancedb/cover.webp?v=c30c96ee48)

## Das Wichtigste in Kürze

-   LanceDB 0.40.0, veröffentlicht am 7. Oktober 2026, ist eine Apache-2.0-Rust-Bibliothek im Anwendungsprozess, mit Python-, JavaScript- und Rust-Clients und ohne laufenden Server.
-   Unter etwa einer Million Zeilen ist ein Vektorindex optional: die FAQ des Herstellers misst 100.000 Paare von 1.000-dimensionalen Vektoren in unter 20 ms und empfiehlt den Index für kleine Tabellen auszulassen.
-   HNSW ist hier kein Index der obersten Ebene — es existiert nur innerhalb von IVF-Partitionen —, und die Doku warnt, dass HNSW-basierte Indizes bei Metadatenfiltern höhere Latenzvarianz zeigen.
-   Die Hybridsuche ist die stärkste Funktion: BM25-Volltextsuche und Vektorsuche, verschmolzen von einem Reciprocal-Rank-Fusion-Reranker, mit Prefiltering als Standard.
-   Der eigene Vergleich des Herstellers nennt für die Open-Source-Edition 10 bis 50 Abfragen pro Sekunde und 500 bis 1.000 ms auf Object Storage, gegen bis zu 10.000 Abfragen und 50 bis 200 ms bei Enterprise.

Auf dieser Seite

1.  [Was LanceDB ist](https://balazscsorba.com/#what-it-is)
2.  [Wie eine Abfrage läuft](https://balazscsorba.com/#how-it-works)
3.  [Welchen Index man baut](https://balazscsorba.com/#indexes)
4.  [Erste Schritte](https://balazscsorba.com/#getting-started)
5.  [Wo es hakt](https://balazscsorba.com/#where-it-shingles)
6.  [Preise](https://balazscsorba.com/#pricing)
7.  [Fazit](https://balazscsorba.com/#verdict)
8.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

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.

![So läuft eine Hybrid-Abfrage Ein Ablauf von links nach rechts: Zeilen werden in einer Lance-Tabelle geschrieben, die auf lokaler Platte oder im Object Storage liegt. Die Tabelle speist zwei Indizes parallel — einen Vektorindex über die Embedding-Spalte und einen BM25-Volltextindex über die Textspalte — und ein Schritt der Reciprocal Rank Fusion verschmilzt beide Ergebnislisten zu einem gerankten Top-k.](https://balazscsorba.com/images/blog/lancedb/diagram-7.webp?v=27f00da6e7)

Eine Hybridsuche: eine Lance-Tabelle speist einen Vektorindex und einen BM25-Index, und die Rangfusion verschmilzt beide zu einer Liste.

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:

Priorität

Index

Kompression

Anmerkung

Maximale Kompression

IVF\_RQ

Etwa 1/32 der Rohgröße

RaBitQ-Quantisierung über IVF

Genauigkeit bis 256 Dimensionen

IVF\_PQ

1/64 bis 1/16 der Rohgröße

Produktquantisierung, Recall über refine\_factor justiert

Bestes Recall-zu-Latenz-Verhältnis

IVF\_HNSW\_SQ

Knapp über 1/4 der Rohgröße

IVF-Partitionen mit HNSW darin, Skalarquantisierung

Höchster Recall, ohne Quantisierung

IVF\_HNSW\_FLAT

Rohgröße plus Graph-Overhead

Die teure, treue Option

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.

**Erst nprobes, dann ef**

Für `IVF_RQ` und `IVF_PQ` lautet die Empfehlung, `nprobes` auf dem Default zu lassen und nur bei zu wenig Recall zu erhöhen; für die IVF\_HNSW-Varianten `nprobes` stehen zu lassen und zuerst `ef` zu justieren, beginnend bei etwa 1,5 mal k bis hoch zu 10 mal k. `refine_factor` gehört zwischen 5 und 50, und ein Filter, der wenige Zeilen trifft, braucht womöglich ein höheres `maximum_nprobes`, um überhaupt `limit` Ergebnisse zu liefern.

## 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.

**Zeilen nach dem Bau**

Neue Zeilen bleiben außerhalb eines bestehenden Index, bis sie mit `optimize()` eingefaltet sind, und bis dahin zahlt eine normale Suche einen langsameren Fallback-Scan, während `fast_search()` ihn überspringt. In der Open-Source-Edition gehört dieser Zeitplan Ihnen: Kompaktierung und Reindexierung sind Aufrufe, die irgendjemand einplanen muss.

## 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.

Engine

Lizenz

Indexoptionen

Betriebsform

LanceDB

Apache-2.0, eingebettet

IVF und IVF-HNSW, BM25, skalar

Eine Bibliothek im eigenen Prozess

Qdrant

Apache-2.0, Server

Filterbares HNSW, Skalar- und Produktquantisierung

Ein Container oder eine verwaltete Cloud

pgvector

PostgreSQL-Lizenz

HNSW und IVFFlat in Postgres

Eine Erweiterung in einer Datenbank, die ohnehin läuft

Weaviate

BSD-3-Clause

HNSW, flat und dynamic

Einzelnes Binary, optionaler Cluster

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.

**Eine Messung vor der Bindung**

Den Index auf echten Daten bauen und den Recall gegen `bypass_vector_index()` messen, der einen exakten Scan ausführt und die Wahrheit liefert. Die Lücke zwischen beiden Antworten ist der tatsächliche Preis der Näherung — und die Zahl, aus der ein Latenzbudget geschrieben wird.

## Quellen

1.  [LanceDB-Quickstart](https://docs.lancedb.com/quickstart)
2.  [LanceDB-Vektorindizes](https://docs.lancedb.com/indexing/vector-index)
3.  [LanceDB-Indexierungsleitfaden](https://docs.lancedb.com/indexing/index)
4.  [LanceDB-Hybridsuche](https://docs.lancedb.com/search/hybrid-search)
5.  [LanceDB Enterprise](https://docs.lancedb.com/enterprise)
6.  [LanceDB-Häufige Fragen](https://docs.lancedb.com/faq/faq-oss)
7.  [LanceDB-Preise](https://lancedb.com/pricing)
8.  [LanceDB auf PyPI](https://pypi.org/project/lancedb/)

## Häufige Fragen

Brauche ich in LanceDB einen Vektorindex?

Anfangs nicht. Die FAQ nennt für Brute-Force-Suche unter 20 ms bei 100.000 Paaren von 1.000-dimensionalen Vektoren und sagt, dass ein Vektorindex jenseits von etwa einer Million Zeilen oder höheren Dimensionen sinnvoll wird; darunter ist der Scan meist schnell genug.

Warum gibt es keinen schlichten HNSW-Index?

In LanceDB ist HNSW eine Unterstruktur innerhalb von IVF-Partitionen statt ein Index der obersten Ebene — das verbindet die Skalierbarkeit von IVF mit dem Recall von HNSW. Verfügbar sind IVF\_HNSW\_FLAT, IVF\_HNSW\_PQ und IVF\_HNSW\_SQ neben den IVF-Varianten mit und ohne Quantisierung.

Wie hält man den Index in der Open-Source-Edition gesund?

Indexbauten laufen asynchron, und angehängte Zeilen bleiben draußen, bis optimize() sie einfaltet. create\_index kehrt sofort zurück, wait\_for\_index wartet auf vollständige Abdeckung, und fast\_search() umgeht den langsameren Fallback-Scan über noch nicht indexierte Zeilen.

Was kostet LanceDB Enterprise?

Es gibt keine öffentliche Preisliste: die Preisseite ist ein Kontaktformular, und Enterprise wird als Managed-Deployment oder Bring-Your-Own-Cloud mit SOC 2 Type II und HIPAA verkauft. Der veröffentlichte Benchmark des Herstellers ergibt etwa 779 Dollar im Monat für 100 Millionen Vektoren.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [Embedding-Modell wählen 2026: Leaderboards, Kosten und ein Vergleichstest mit eigenen Daten](https://balazscsorba.com/de/blog/embedding-model-selection-2026)
-   [Contextual Retrieval und Late Chunking: RAG-Chunks ihren Kontext zurückgeben](https://balazscsorba.com/de/blog/contextual-retrieval-late-chunking)
-   [Zugriffskontrolle für RAG: berechtigungsbewusstes Retrieval ohne Datenlecks](https://balazscsorba.com/de/blog/rag-access-control-permissions)
-   [RAG über Produktkataloge: aus PIM-Daten Antworten machen, die halten](https://balazscsorba.com/de/blog/rag-product-catalog-pim-data)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)