2026-01-23

Ankündigung: Vortex-Unterstützung in DuckDB

Guillermo Sanchez, SpiralDB Team

Ich denke, es lohnt sich, diese Einleitung mit ein paar Worten zum etablierten Format für spaltenorientierte Daten zu beginnen. Parquet hat Erstaunliches für die Analytik geleistet. Wer sich noch an die Zeiten erinnert, in denen CSV die bessere Alternative war, weiß, wie wichtig Parquet ist. Auch wenn sich die Spezifikation weiterentwickelt hat, hat Parquet Design-Einschränkungen. Eine besondere Einschränkung: Es ist blockkomprimiert, und Engines müssen Pages dekomprimieren, bevor sie weiter filtern, Werte dekodieren usw. können. Seit einiger Zeit arbeiten Forscher und Unternehmen an Alternativen zu Parquet, die einige dieser Schwächen verbessern. Vortex vom SpiralDB-Team ist eine davon.

Was ist Vortex?

Vortex ist ein erweiterbares Open-Source-Format für spaltenorientierte Daten. Es entstand, um heterogene Compute-Muster und unterschiedliche Datenmodalitäten zu bedienen. Aber was heißt das?

Das Projekt wurde im August 2025 vom SpiralDB-Team an die Linux Foundation gespendet.

Vortex bietet unterschiedliche Layouts und Encodings für verschiedene Datentypen. Zu den bemerkenswertesten gehören ALP für Gleitkomma-Encoding oder FSST für String-Encoding. Diese leichtgewichtige Kompressionsstrategie hält Datengrößen klein und ermöglicht gleichzeitig eines der wichtigsten Features von Vortex: Compute-Funktionen. Weil das kodierte Layout der Daten bekannt ist, kann Vortex beliebige Ausdrücke auf komprimierten Daten ausführen. So kann ein Vortex-Reader zum Beispiel Filterausdrücke in Storage-Segmenten ausführen, ohne Daten zu dekomprimieren.

Wir erwähnen heterogene Compute, um zu betonen, dass Vortex mit der Idee optimierter Layouts für unterschiedliche Datentypen entworfen wurde – einschließlich Vektoren, großem Text oder sogar Bild und Audio – aber auch, um CPU- oder GPU-Sättigung zu maximieren. Die Idee: Dekompression wird bis ganz zur GPU oder CPU aufgeschoben und ermöglicht, was Vortex „late materialization“ nennt. Das FastLanes-Encoding, ein Projekt mit Ursprung am CWI (wie DuckDB), ist einer der Haupttreiber hinter diesem Feature.

Vortex unterstützt außerdem dynamisch geladene Bibliotheken (ähnlich DuckDB-Extensions), um neue Encodings für bestimmte Typen sowie spezifische Compute-Funktionen bereitzustellen, z. B. für Geodaten. Ein weiteres sehr interessantes Feature ist das Einbetten von WebAssembly in die Datei, sodass der Reader von spezifischen Compute-Kernels für die Datei profitieren kann.

Neben DuckDB bieten bereits andere Engines wie DataFusion, Spark und Arrow eine Integration mit Vortex.

Mehr Informationen finden Sie in der Vortex-Dokumentation.

Die DuckDB-Vortex-Erweiterung

DuckDB ist eine Datenbank, ja, wie der Name sagt – aber sie wird auch weithin als Engine genutzt, um viele verschiedene Datenquellen abzufragen. Über Kern- oder Community-Extensions kann DuckDB integrieren mit:

• Datenbanken wie Snowflake, BigQuery oder PostgreSQL.
• Lakehouse-Formaten wie Delta, Iceberg oder DuckLake.
• Dateiformaten, allen voran JSON, CSV, Parquet und zuletzt Vortex.

Die Community ist sehr kreativ geworden: Heutzutage können Sie mit DuckDB sogar YAML und Markdown über Community Extensions lesen.

All das ist möglich dank des DuckDB-Extension-Systems, das es relativ einfach macht, Logik für unterschiedliche Dateiformate oder externe Systeme umzusetzen.

Das SpiralDB-Team hat eine DuckDB-Erweiterung gebaut. Zusammen mit dem DuckLabs-Team haben wir die Erweiterung als Kern-DuckDB-Erweiterung verfügbar gemacht, damit die Community Vortex als First-Class-Citizen in DuckDB nutzen kann.

Beispielnutzung

Installation und Nutzung der Vortex-Erweiterung sind sehr einfach:

INSTALL vortex;
LOAD vortex;

Danach können Sie sie ähnlich wie andere Erweiterungen wie Parquet zum Lesen und Schreiben nutzen.

SELECT * FROM read_vortex('my.vortex');

COPY (SELECT * FROM generate_series(0, 3) t(i))
TO 'my.vortex' (FORMAT vortex);

Warum Vortex und DuckDB?

Vortex beansprucht, vor allem bei drei Use Cases gut zu sein:

• Klassische SQL-Analytics: Durch späte Dekompression und Compute-Ausdrücke auf komprimierten Daten kann Vortex Daten im Storage-Segment herunterfiltern und so I/O und Speicherverbrauch reduzieren.
• Machine-Learning-Preprocessing-Pipelines: Durch die Unterstützung einer großen Vielfalt an Encodings für unterschiedliche Datentypen beansprucht Vortex, Daten effektiv zu lesen und zu schreiben – ob Audio, Text, Bilder oder Vektoren.
• KI-Modelltraining: Encodings wie FastLanes erlauben eine sehr effiziente Kopie von Daten auf die GPU. Vortex zielt darauf, Daten direkt von S3 Object Storage auf die GPU zu kopieren.

Das Versprechen effizienterer I/O und Speichernutzung durch späte Dekompression ist ein guter Grund, DuckDB und Vortex für SQL-Analytics auszuprobieren. Wenn Sie außerdem Analytics auf einheitlichen Datensätzen fahren, die für mehrere Use Cases genutzt werden, einschließlich Preprocessing-Pipelines und KI-Training, kann Vortex ein guter Kandidat sein, weil es genau für diese Bandbreite entworfen wurde.

Performance-Experiment

Für alle Zahlenhungrigen haben wir einen TPC-H-Benchmark Scale Factor 100 mit DuckDB ausgeführt, um zu verstehen, wie Vortex als Storage-Format im Vergleich zu Parquet abschneidet. Wir haben versucht, den Benchmark so fair wie möglich zu machen. Das sind die Parameter:

• Ausgeführt auf einem Mac M1 mit 10 Kernen und 32 GB Speicher.
• Der Benchmark führt jede Abfrage 5 Mal aus, der Durchschnitt fließt in den Abschlussbericht.
• Die DuckDB-Verbindung wird nach jeder Abfrage geschlossen, um Läufe „kälter“ zu machen und zu vermeiden, dass DuckDBs Caching (besonders bei Parquet) die Ergebnisse beeinflusst. OS-Page-Caching hat in Folgeläufen einen Einfluss, den wir anerkennen und den ersten Lauf trotzdem behalten.
• Jede TPC-H-Tabelle ist eine einzelne Datei, das heißt die lineitem-Dateien für Parquet und Vortex sind ziemlich groß (beide um die 20 GB). So können wir den Effekt von Globbing und vielen kleinen Dateien ignorieren.
• Die Datendateien für den Benchmark werden mit tpchgen-rs erzeugt und mit DuckDBs Parquet- und Vortex-Erweiterungen herauskopiert.
• Wir haben Vortex mit Parquet v1 und v2 verglichen. Die v2-Spezifikation erlaubt deutlich schnelleres Lesen als v1, aber viele Writer unterstützen das nicht, deshalb fanden wir es sinnvoll, beides aufzunehmen.

Die Ergebnisse sind sehr gut. Der TPC-H-Benchmark läuft 18 % schneller gegenüber Parquet V2 und 35 % schneller als Parquet V1 (gemessen am geometrischen Mittel, dem empfohlenen Ansatz).

Ein weiteres interessantes Ergebnis ist die Standardabweichung über die Läufe. Bei Parquet gab es einen erheblichen Unterschied zwischen dem ersten (und kältesten) Lauf jeder Abfrage und den Folgeläufen, während Vortex über alle Läufe sehr gut abschnitt – mit deutlich kleinerer Standardabweichung.

Die Zeiten schwankten zwischen verschiedenen Läufen desselben Benchmarks, und Folgeläufe haben ähnliche Ergebnisse mit leichten Abweichungen geliefert. Die Unterschiede zwischen Parquet v2 und Vortex lagen immer bei etwa 12–18 % im geometrischen Mittel und etwa 8–14 % in den Gesamtzeiten. Benchmarking ist sehr schwer!

Fazit

Vortex ist eine sehr interessante Alternative zu etablierten spaltenorientierten Formaten wie Parquet. Der Fokus auf leichtgewichtige Kompressions-Encodings, späte Dekompression und Compute-Ausdrücke auf komprimierten Daten macht es für eine breite Palette von Use Cases interessant. Mit Blick auf DuckDB sehen wir, dass Vortex für analytische Abfragen bereits sehr performant ist und auf den TPC-H-Benchmark-Abfragen auf Augenhöhe oder besser als Parquet v2 liegt.

Vortex ist seit Version 0.36.0 rückwärtskompatibel, die vor mehr als 6 Monaten erschienen ist. Vortex steht jetzt bei Version 0.56.0.