2026-05-21

Das Lance-Lakehouse-Format in DuckDB ausprobieren

LanceDB team and Guillermo Sanchez

Mit der lance-Erweiterung können DuckDB-Nutzer Lance-Datensätze über dieselbe vertraute SQL-Schnittstelle abfragen (über CLI oder SDKs) und bekommen dabei Fähigkeiten für KI- und Retrieval-Workloads dazu. Dieser Blogbeitrag zeigt, warum Lance gut zu Workloads passt, die Speicherung und Abfrage von Vektoren, reichhaltige Tabellenoperationen und KI-orientierte Zugriffsmuster brauchen, und gleichzeitig scan-freundliche analytische Lasten in der Fläche tragen. Mit DuckDB wird das Abfragen solcher Datensätze in SQL trivial.

In diesem Beitrag ist von „Retrieval-Workloads“, „KI-Datenmustern“ oder „KI-Datensätzen“ die Rede. Mit „Retrieval-Workloads“ meinen wir Abfragen, die Zeilen nach Ähnlichkeit oder Keyword-Relevanz finden, etwa Vektorsuche und Volltextsuche, nicht nach exakten Filtern oder Aggregationen. Mit „KI-Datenmustern“ meinen wir Datensätze, die Embeddings, Bilder oder Audio neben skalarer Metadaten mischen.

Was ist Lance?

Lance ist ein offenes Lakehouse-Format für moderne ML- und KI-Workloads. Anders als Parquet ist Lance Dateiformat, Tabellenformat und leichtgewichtige Katalogspezifikation in einem. Auf Tabellenformatebene unterstützt Lance Versionierung, Schemaevolution, Indizes und transaktionale Updates über MVCC und ACID-ähnliche Semantik. Praktisch heißt das: Lance ist für Datensätze gebaut, die sich über die Zeit ändern und mehr brauchen als Read-only-Scans.

Das ist wichtig, weil viele KI-Datensätze längst nicht mehr nur Zeilen skalarer Werte sind. Oft stecken Embeddings, langer Text, Bilder, Audio, Filtermetadaten und Indizes für Retrieval darin. Ein Format für diese Workloads muss mehr können, als Spalten effizient zu speichern und zu scannen. Es muss Suche, Updates und Lifecycle-Operationen tragen, ohne Nutzer in mehrere Systeme zu zwingen.

Das mentale Modell bleibt vertraut, wenn man von Parquet kommt: spaltenorientierte Daten in einem offenen Format, abgefragt mit Standard-Analysetools. Lances fragmentbasiertes Layout speichert Daten in kleinen spaltenorientierten Chunks. Das ermöglicht effizienten Random Access ohne Abstriche bei Scan-Performance oder Speicherauslastung – etwas, das in spaltenorientierten Formaten historisch schwer war und das das Lance-Team in diesem Paper von 2025 zu adaptiven strukturellen Encodings untersucht.

Auf der Evolutionsseite schreibt das Hinzufügen von Spalten oder das Nachfüllen bestehender Zeilen nur neue Dateien, bestehende bleiben unberührt. Schemaänderungen bleiben damit in der Praxis leichtgewichtig, nützlich für Workflows, in denen Spalten schrittweise dazukommen, etwa abgeleitete Features oder Embeddings an einem bestehenden Datensatz.

Die Lance-DuckDB-Erweiterung

Die lance-Erweiterung holt Lance als Teil des SQL-Workflows nach DuckDB. Sie können Lance-Datensätze direkt lesen, über COPY schreiben, als Tabellen-Namespaces anhängen, Indizes bauen und mit gewöhnlichem DuckDB-SQL abfragen. Darüber hinaus legt die Erweiterung Lance-eigene Suchfunktionen als SQL-Tabellenfunktionen frei.

Das passt zu der Art, wie DuckDB schon genutzt wird: als einzelne, eingebettete SQL-Query-Engine über viele Datenquellen und Dateiformate. Mit der Lance-Erweiterung bleibt DuckDB die vertraute Query-Engine, Lance liefert darunter Storage, Indexierung und Suche – besonders hilfreich, wenn die Daten multimodal sind und Embeddings enthalten.

Beispielnutzung

Installation und Einsatz der Erweiterung sind geradlinig:

INSTALL lance;
LOAD lance;

SELECT *
FROM 'path/to/dataset.lance'
LIMIT 10;

DuckDB kann Lance-Datensätze auch direkt schreiben:

COPY (
    SELECT *
    FROM (
        VALUES
            (1::BIGINT, 'duck', [0.9, 0.7, 0.1]::FLOAT[3]),
            (2::BIGINT, 'horse', [0.3, 0.1, 0.5]::FLOAT[3]),
            (3::BIGINT, 'dragon', [0.5, 0.2, 0.7]::FLOAT[3])
        ) AS t(id, animal, vec)
) TO 'path/to/out.lance' (FORMAT lance, mode 'overwrite');

Sobald die Daten in Lance liegen, kann DuckDB sie mit Lance-eigenen Suchoperatoren abfragen. Hybrid Search kombiniert zum Beispiel Vektorähnlichkeit und Keyword-Relevanz in einer SQL-Abfrage:

SELECT id, text, _hybrid_score, _distance, _score
FROM lance_hybrid_search(
    'path/to/dataset.lance',
    'vec',
    [0.1, 0.2, 0.3, 0.4]::FLOAT[4],
    'text',
    'puppy',
    k = 10,
    prefilter = false,
    alpha = 0.5,
    oversample_factor = 4
)
ORDER BY _hybrid_score DESC;

Die Erweiterung stellt außerdem lance_vector_search(...) für Vektorähnlichkeitssuche und lance_fts(...) für Volltextsuche bereit, sodass Nutzer den Retrieval-Modus wählen können, der zum Workload passt.

Für tabellenartigen statt pfadbasierten Zugriff hängen Sie ein Verzeichnis als Lance-Namespace an:

ATTACH 'path/to/dir' AS ns (TYPE lance);

SELECT count(*)
FROM ns.main.my_table;

Auch die Indexerzeugung läuft über SQL. Ein Vektorindex auf einem Lance-Datensatz entsteht zum Beispiel so:

CREATE INDEX vec_idx ON 'path/to/dataset.lance' (vec)
USING IVF_FLAT WITH (num_partitions = 1, metric_type = 'l2');

Die Oberfläche der Erweiterung geht weit über Read-only-Scans hinaus. In der aktuellen Implementierung kann DuckDB:

• Lance-Datensätze per direktem Pfad-Scan lesen
• Lance-Datensätze mit COPY ... TO ... (FORMAT lance) schreiben und anhängen
• Vektor-, Volltext- und Hybridsuche mit SQL-Funktionen ausführen
• Lokale Verzeichnisse oder eigene Kataloge über REST-Namespaces anhängen
• Tabellen in angehängten Namespaces anlegen, aktualisieren, löschen, mergen und ändern
• Vektor-, Skalar- und Volltextindizes anlegen und verwalten
• Wartungsoperationen wie Compaction, Cleanup und Indexoptimierung ausführen

Die Erweiterung ist also nicht nur ein Dateileser: DuckDB-Nutzer können Lance als operatives Tabellenformat von innen aus SQL bedienen.

Warum Lance und DuckDB?

Die Kombination aus Lance und DuckDB überzeugt aus drei Gründen.

Erstens gibt sie Nutzern eine SQL-Oberfläche für Analytics plus Retrieval. Derselbe DuckDB-Workflow kann einen Datensatz scannen, filtern, mit anderen Tabellen joinen, Aggregationen rechnen und dann Vektor- oder Hybridsuche über das Ergebnis laufen lassen. Das passt zu KI-Anwendungen, in denen Retrieval nur ein Schritt in einer größeren analytischen Pipeline ist.

Zweitens ist Lance ein Tabellenformat für mehr als klassische Analytics. Viele KI-Pipelines brauchen versionierte Datensätze, Updates, Deletes, MERGE-artige Änderungen, Indexverwaltung und Schemaevolution. Die DuckDB-Erweiterung legt das über SQL frei, Nutzer müssen DuckDB also nicht verlassen, nur weil der Datensatz mehr tut als analytische Reads zu bedienen.

Drittens skaliert der Workflow von lokalen Dateien zu Remote-Storage, ohne das mentale Modell zu wechseln. Sie können mit einem lokalen lance-Datensatz starten und dann auf Object Storage umziehen.

Die Erweiterung unterstützt außerdem REST-Namespaces, DuckDB kann sich also mit einem entfernten Lance-Katalog verbinden (einschließlich LanceDB Enterprise) und ihn wie eine angehängte Datenbank behandeln. Der Weg von lokal nach remote bleibt damit schrittweise, nicht disruptiv.

Kurz: DuckDB bleibt die vertraute SQL-Engine, Lance ergänzt Storage- und Indexfunktionen, die besonders nützlich sind, wenn derselbe Datensatz Analytics und Retrieval speist.

Performance-Experiment

LAION ist ein offener Datensatz aus Bild/Caption-Paaren, die vom öffentlichen Web gescrapt wurden, ursprünglich für die Forschung an Modellen wie CLIP, die einen gemeinsamen Embedding-Raum für Bilder und Text lernen. Die vollständige Veröffentlichung umfasst Milliarden Paare. Für dieses Experiment haben wir das Subset lance-format/laion-1m auf Hugging Face Hub genutzt, das sich lokal leicht reproduzieren lässt.

Jede Zeile trägt eine Caption, ein 768-dimensionales CLIP-Bild-Embedding, die rohen Bildbytes und skalare Metadaten wie Breite, Höhe und NSFW-Flags. Diese Mischung aus Skalar-, Text-, Vektor- und Blob-Daten in einer Tabelle eignet sich gut zum Vergleich von Formaten und ist strukturell anders als die breiten, flachen Schemas wie TPC-H oder ClickBench, die traditionell für analytische Benchmarks genutzt werden.

Der öffentliche Hugging-Face-Export, den der Benchmark nutzt, materialisiert lokal derzeit 69.632 Zeilen, nicht den vollständigen Millionen-Zeilen-Quelldatensatz. Der Runner lädt zuerst die öffentlichen Parquet-Shards herunter und baut dann alle lokalen Artefakte aus derselben Baseline: eine LZ4-komprimierte Parquet-Datei, eine indizierte DuckDB-Datenbank und einen Lance-Datensatz. Erzeugte Dateien werden über Läufe hinweg wiederverwendet, der initiale Download ist der einzige Netzwerkschnitt.

Die Experimente liefen auf einem Apple MacBook Pro mit 10-Kern-M1-Max-CPU und 32 GB RAM, mit DuckDB 1.5.2.

Der Benchmark nutzte DuckDB als Query-Engine für die folgenden drei Storage-Formate:

• Parquet: DuckDB scannt die LZ4-komprimierte Parquet-Baseline direkt, ohne Hilfsindizes.
• DuckDB indexed: dieselbe Baseline in einer DuckDB-Tabelle, mit DuckDBs Erweiterungen vss (HNSW) und fts sowie Skalarindizes auf Filterspalten. Das ist der typische „selbst in DuckDB bauen“-Stack.
• Lance native: dieselbe Baseline als Lance-Datensatz mit Vektorindex, Volltextindex und nativem Blob-Storage, abgefragt über die DuckDB-lance-Erweiterung.

Die Workloads sind über die drei Pfade nach Aufgabe ausgerichtet, auch wenn das genaue SQL je nach Storage-/Indexierungsbackend abweicht:

• fts: Zeilen per Keyword-Suche über den Caption-Text finden.
• vector_exact: Nächste-Nachbarn-Suche über die CLIP-Embedding-Spalte ohne approximativen Vektorindex.
• vector_indexed: Nächste-Nachbarn-Suche über dieselbe Embedding-Spalte mit dem verfügbaren Vektorindex.
• hybrid: Text- und Vektorsuche in einer Retrieval-Abfrage kombinieren und die bestplatzierten Treffer aus beiden Signalen zurückgeben.
• blob_read: Bildbytes für ausgewählte Zeilen holen, also Random Access auf große Binärwerte statt nur Skalar- oder Vektorspalten.

Jeder Workload läuft standardmäßig fünfmal, die Tabellen unten berichten den Durchschnitt. Die vollständigen Skripte und SQL-Abfragen liegen im Benchmark-Verzeichnis laion_1m.

Cold Results

Die folgende Tabelle läuft jeden Workload kalt, in einem frischen DuckDB-Prozess, und erfasst damit Prozessstart, Dateiöffnen und First-Query-Kosten. Das kommt dem am nächsten, was ein einmaliges Skript oder ein Cronjob sieht.

Im Cold Run sticht Lance bei den Workloads vector_indexed und hybrid hervor. DuckDBs eigenes Format schneidet bei vector_exact und fts gut ab, blob_read liegt etwa gleichauf. Parquet ist für Vektorsuchen oder Blob-Reads nicht gut optimiert, schlägt sich aber bei einer einfachen regexbasierten Textsuche gut.

Warm Results

Die Warm Results stammen aus einem Lauf aller Workloads in einer einzigen DuckDB-Sitzung nach einem stillen Warmup, sodass Caches, memory-mapped Pages und geladene Indizes bereits warm sind.

Wenn Caches und Indizes warm sind, sind DuckDB und Lance bei Retrieval-Workloads deutlich schneller als Parquet.

Fazit

Lance ist ein vergleichsweise neues offenes Lakehouse-Format. Es ist für Datensätze gedacht, die sich über die Zeit ändern, mehr als skalare Werte enthalten und Suche und Retrieval neben klassischen Scan-Workloads tragen sollen. Von DuckDB aus macht die Erweiterung diese Fähigkeiten über SQL verfügbar und behält den vertrauten eingebetteten Workflow. Die Benchmark-Ergebnisse zeigen, besonders in Cold Runs, dass Lance für Vektor- und Hybridsuche eine gute Alternative zu DuckDBs eigenem Format ist.

Die Lance-Unterstützung in DuckDB entstand in Zusammenarbeit von DuckLabs und LanceDB.