2025-09-08

Big Data unterwegs: DuckDB auf dem Framework Laptop 13

Gábor Szárnyas

Hintergrund

Als DuckDBs Design 2018 skizziert wurde, war eine zentrale Einsicht, dass Laptops stark genug geworden waren, um die meisten analytischen Workloads zu bewältigen, die Data Scientists ihnen zumuten. Das machte es machbar, eine neue analytische Datenbank als Single-Node-System umzusetzen, das überall läuft – einschließlich Laptops: DuckDB.

2020 hat die Veröffentlichung von Apple Silicon DuckDB-auf-Laptop-Setups einen großen Performance-Schub gegeben. Heute haben moderne MacBooks CPUs mit einem Dutzend plus Kernen, viel Speicher und schnelle Platten – all das nutzt DuckDB sehr gern. Das hat aber seinen Preis: Hier in den Niederlanden kostet ein MacBook Pro mit 128 GB RAM und 8 TB Platte mehr als 8.500 Euro.

Inzwischen gab es auch in der x86-Welt deutliche Sprünge. AMDs Ryzen AI 300-Ultrathin-Mobilprozessoren, 2024 erschienen, packen bis zu 12 Kerne und 24 Threads. DuckDB läuft ebenso gern auf der x86_64-Architektur wie auf arm64-Prozessoren, also wollten wir wissen, wie DuckDB auf den neuen AMDs performt.

Setup

Für dieses Experiment haben wir das 13-Zoll-Modullaptop von Framework gekauft und es mit 128 GB RAM und 8 TB Platte ausgestattet – alles für knapp unter 3.000 Euro.

Wir haben Omarchy 2.0 installiert, eine Arch-Linux-basierte Distribution mit lebendiger Community und First-Class-Support für Framework-Laptops. Zusammenbau des Laptops und Installation von Omarchy haben insgesamt weniger als eine Stunde gedauert. Die Installation des DuckDB-Kommandozeilen-Clients hat mit dem Installer-Skript nur Sekunden gedauert:

curl https://install.duckdb.org | sh

Wir haben das Theme auf Osaka Jade geändert für einen matrixartigeren Look und sind losgelegt:

Experimente

Um zu sehen, wie dieses Laptop performt, haben wir ein paar Benchmarks zu Lade- und Query-Verarbeitungszeiten ausgeführt.

CSV-Laden

Um die CSV-Ladeperformance zu messen, haben wir einen unserer Lieblingsdatensätze genutzt: die niederländischen Bahnfahrten. Wir haben den vollen Datensatz der letzten 80 Monate genommen (Januar 2019 bis August 2025). Datei holen und entpacken geht so:

wget https://blobs.duckdb.org/nl-railway/railway-services-80-months.zip
unzip railway-services-80-months.zip

Das resultierende Verzeichnis ist etwa 20 GB. Schauen wir, wie schnell DuckDB die Dateien laden kann:

duckdb

.timer on
CREATE TABLE services AS FROM 'services/services-*.csv';
-- Run Time (s): real 10.219 user 217.596664 sys 7.348692

Es stellt sich heraus, dass DuckDB 20 GB CSV-Dateien in nur 10,2 Sekunden in den Speicher laden kann, bei 1,96 GB/s!

TPC-H-Benchmarks

Für die Query-Performance haben wir TPC-H genutzt. Wir haben TPC-H-Abfragen schon in allen möglichen Umgebungen ausgeführt und waren neugierig: Wie weit kann DuckDB auf diesem Laptop skalieren?

Datenerzeugung

Natürlich brauchten wir zuerst große TPC-H-Datensätze, und wir mussten sie lokal erzeugen – das Herunterladen könnte Tage dauern. Glücklicherweise konnten wir das Tool tpchgen-cli nutzen, eine reine Rust-Implementierung des TPC-H-Generators, die großskalige Datensätze auf dem Laptop in nur wenigen Stunden erzeugt. Wir haben die Daten als Parquet-Dateien erzeugt und in DuckDB geladen.

Omarchy kommt standardmäßig mit dem btrfs-Dateisystem. Wir haben ein Verzeichnis für die erzeugten Daten angelegt und Copy-on-Write deaktiviert (siehe die Konfigurationsdetails).

SF3.000

Zuerst haben wir alle 22 TPC-H-Abfragen auf dem SF3.000-Datensatz ausgeführt, das entspricht 3 TB CSV-Dateien. Die Gesamtlaufzeit der Abfragen lag bei 47,5 Minuten, das geometrische Mittel der Query-Laufzeit bei 86,5 Sekunden.

Während der Experimente haben wir bemerkt, dass die Unterseite des Laptops über 45 Grad Celsius heiß wurde: Die Tastatur war noch benutzbar, aber man will diese Maschine beim Datenknacken nicht auf dem Schoß haben. Die überschüssige Hitze führt natürlich auch zu Thermal Throttling, das die CPU heruntertakten lässt und die Abfragen langsamer macht. Solche Probleme kennen wir: Letztes Jahr haben wir ein iPhone 16 in Trockeneis getaucht, um die Kühlung zu verbessern, das schien beim Laptop aber unpraktisch, also haben wir uns praktischere Maßnahmen gesucht.

Für unseren „kühlen Lauf“ haben wir einfach 5-minütige Pausen zwischen den Abfragen eingefügt, damit das Laptop abkühlen kann. Das hat sehr gut funktioniert: Die Gesamtlaufzeit der Abfragen (ohne Kühlpausen) sank auf 30,8 Minuten, das geometrische Mittel auf 58,2 Sekunden – 32 % Speedup!

Die meisten interaktiven Data-Science-Workloads wechseln Query-Ausführung mit Zeit für Coding und Analyse – das gibt dem Laptop genau solche Kühlphasen.

SF3.000 auf Akku

Bisher haben wir die Experimente mit eingestecktem Ladegerät ausgeführt. Aber Laptops sind schließlich tragbare Geräte, also waren wir neugierig: Können wir die Abfragen auf dem SF3.000-Datensatz auch unterwegs ausführen?

Es geht! Alle TPC-H-Abfragen auf dem SF3.000-Datensatz dauerten 46,9 Minuten (geometrisches Mittel 83,7 Sekunden) und haben einen voll geladenen Akku auf etwa 30 % gebracht. Wenn Sie trotzdem Terabyte-große Datensätze auf dem Laptop analysieren, sollten Sie zur Sicherheit eine Powerbank mitnehmen.

TPC-H SF10.000

Schließlich war es Zeit für die ultimative Herausforderung: Schafft dieses Laptop den SF10.000-Datensatz, entsprechend 10 TB CSV-Dateien? Um das herauszufinden, haben wir:

• die Daten erzeugt – etwa 4 TB in Parquet-Dateien,
• die Dateien in DuckDB geladen – etwa 2,7 TB im DuckDB-Dateiformat,
• die Parquet-Dateien aufgeräumt – im Wissen, dass der Extra-Platz später nützlich wird,
• die Abfragen ausgeführt – und gelegentlich gesehen, wie DuckDB 3,6 TB auf die Platte auslagert,

und sie am Ende ohne Probleme abschließen sehen!

Der Lauf dauerte insgesamt 4,2 Stunden, das geometrische Mittel der Query-Laufzeit lag bei 6,6 Minuten.

Wenig überraschend trat auch hier Thermal Throttling auf, also haben wir das Experiment mit Kühlpausen wiederholt. Die Gesamt-Query-Laufzeit sank auf 3,8 Stunden, das geometrische Mittel auf 5,7 Minuten (14 % Speedup). Die Unterschiede sind also kleiner als beim SF3.000-Datensatz – das ergibt Sinn: Bei den längeren Query-Laufzeiten haben die Kühlpausen nicht mehr so viel Wirkung.

Fazit

Kurz: Sie können für weniger als 3.000 Euro ein Laptop bauen, das CSV-Dateien mit fast 2 GB/s lädt, die volle Palette der TPC-H-Abfragen auf SF3.000 auf Akku ausführt und alle Abfragen auf dem SF10.000-Datensatz abschließt.

Das ist kein offizieller TPC-H-Lauf, aber es lohnt sich zu erwähnen: Unter den aktuellen auditierten SF10.000-TPC-H-Implementierungen kostet das günstigste Setup, das TPC-H SF10.000 schafft, deutlich über 1 Million Euro bzw. 1,2 Millionen US-Dollar – unser Setup kostet weniger als 0,3 % davon und erledigt den Job für 99 % der Data-Science-Workloads.

Vergessen Sie nur nicht, zwischendurch Pause zu machen, damit das Laptop etwas abkühlen kann.

Anhang

Kostenaufschlüsselung

Hier die Kostenaufschlüsselung des Laptops zu Einzelhandelspreisen in Euro (einschließlich 21 % niederländischer MwSt.). Die Teile wurden im August 2025 gekauft.

Hinweis: Framework verkauft derzeit nur 96-GB-Speicherkits, aber sowohl Mainboard als auch CPU können 128 GB (2 × 64 GB) Kits.

Dateisystem-Konfiguration

In unseren ersten Experimenten hatten wir intermittierende Checksum-Fehler vom btrfs-Dateisystem in dmesg, sichtbar als BTRFS warning (device dm-0): csum failed ...-Meldungen und Abstürze. Wir haben umfangreiche Platten- und Speichertests ausgeführt, die keine Probleme zeigten, und versucht, den Fehler auf einer AWS-EC2-Cloud-Instanz mit btrfs zu reproduzieren – dort konnten wir das Problem nicht beobachten. Wenn Sie einen Einblick in diesen Fehler haben oder einen Reproducer, öffnen Sie bitte ein Issue – wir schicken Ihnen gern etwas DuckDB-Merch!

Weil DuckDBs Storage bereits Checksums nutzt, können wir Copy-on-Write zusammen mit Checksums deaktivieren für die Experimente über das NOCOW-Attribut (+C), ohne Datenkorruption zu riskieren:

sudo chattr +C duckdb-tpch-experiment
lsattr -d duckdb-tpch-experiment