Big Data auf dem günstigsten MacBook verarbeiten

 (duckdb.org)
4 Punkte von GN⁺ 2026-03-13 | 2 Kommentare | Auf WhatsApp teilen
  • Mit den Benchmarks ClickBench und TPC-DS SF300 wurde gemessen, wie gut das neueste MacBook Neo Datenbank-Workloads bewältigt.
  • Für den Test wurde ein Modell mit Apple A18 Pro mit 6 Kernen, 8 GB Arbeitsspeicher und 512 GB SSD verwendet; getestet wurde mit DuckDB v1.5.0 und v1.4.4 LTS.
  • In ClickBench zeigte das MacBook Neo bei Cold Runs bessere Ergebnisse als Cloud-Instanzen, was auf die schnellen Zugriffszeiten der lokalen NVMe-SSD zurückgeführt wird.
  • Im Test TPC-DS SF300 kam es bei einigen Abfragen zu Disk Spilling von bis zu 80 GB, dennoch wurden alle Queries in 79 Minuten abgeschlossen und stabil ausgeführt.
  • Für alltägliche Big-Data-Aufgaben gibt es Grenzen, als Notebook für DuckDB-Clients ist es jedoch nachweislich gut nutzbar.

Spezifikationen des MacBook Neo und Ziel des Tests

  • Das von Apple veröffentlichte MacBook Neo wurde zwar als Gerät für Studierende und Schreibende vorgestellt, das DuckDB-Team überprüfte seine Leistung jedoch im Sinne der Philosophie „Big Data auf dem Notebook“.
    • Beim in Europa verkauften Modell ist kein Ladegerät enthalten; mitgeliefert werden nur das Notebook und ein USB-C-Kabel.
    • Als Optionen stehen nur 256-GB- oder 512-GB-SSDs zur Verfügung; im Test wurde das 512-GB-Modell verwendet.
  • Ausgestattet mit 8 GB Arbeitsspeicher und dem Apple A18 Pro (6 Kerne).
    • Das iPhone 16 Pro mit demselben Chip hatte in einem früheren Test TPC-H SF100 bereits in unter 10 Minuten abgeschlossen.

ClickBench-Benchmark

  • ClickBench ist ein Benchmark für analytische Datenbanken, der 43 Queries auf einer einzelnen Tabelle mit 100 Millionen Zeilen ausführt.
    • Größe: 14 GB im Parquet-Format, 75 GB als CSV
  • DuckDB v1.5.0 wurde für macOS portiert und ausgeführt; das Speicherlimit wurde auf 5 GB gesetzt, um die Abhängigkeit von Swap zu verringern.
  • Vergleichssysteme:
    • MacBook Neo (2P+4E-Kerne, 8 GB RAM)
    • AWS c6a.4xlarge (16 vCPU, 32 GB RAM)
    • AWS c8g.metal-48xl (192 vCPU, 384 GB RAM)

Ergebnisse und Analyse

  • Ergebnisse der Cold Runs:
    • Das MacBook Neo schloss alle Queries in unter einer Minute ab und erzielte mit einem Median von 0,57 Sekunden die schnellste Leistung.
    • Die Cloud-Instanzen waren aufgrund der Latenz von Network Storage langsamer.
  • Ergebnisse der Hot Runs:
    • Die Gesamtausführungszeit des MacBook Neo verbesserte sich um etwa 10 %.
    • c8g.metal-48xl war insgesamt am schnellsten, das MacBook Neo war im Median jedoch besser als c6a.4xlarge.
    • Die Gesamtausführungszeit lag etwa 13 % über der von c6a.4xlarge.

TPC-DS-Benchmark

  • Verwendet wurde DuckDB v1.4.4 LTS mit einem Speicherlimit von 6 GB.
  • SF100:
    • Median der Query-Zeit: 1,63 Sekunden, insgesamt 15,5 Minuten
  • SF300:
    • Median der Query-Zeit: 6,90 Sekunden
    • Disk Spilling von bis zu 80 GB
    • Query 67 dauerte 51 Minuten, alle Queries wurden jedoch innerhalb von 79 Minuten abgeschlossen.

Kaufüberlegungen

  • Für kontinuierliche Big-Data-Verarbeitung sind Disk I/O (1,5 GB/s) und 8 GB Arbeitsspeicher begrenzende Faktoren.
    • Air- oder Pro-Modelle (3–6 GB/s) oder Notebooks mit anderem Betriebssystem sind besser geeignet.
  • Wenn DuckDB in der Cloud läuft und lokal als Client genutzt wird, ist das MacBook Neo dennoch ausreichend nützlich.
    • Auch gelegentliche lokale Datenverarbeitung ist stabil möglich.

Fazit

  • Das MacBook Neo kann trotz seines niedrigen Preises große Daten-Workloads auf DuckDB-Basis vollständig bewältigen.
  • Auch im Vergleich mit Cloud-Umgebungen zeigt sich der Vorteil der lokalen SSD deutlich.
  • Es wird als Gerät mit Minimalausstattung bewertet, das Entwicklern und Datenanalysten zugleich Mobilität und ausreichende Leistung für Experimente bieten kann.

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2026-03-13
Hacker-News-Kommentare

  • Ich wollte mit diesem kleinen MacBook Neo einmal „echte Entwicklungsarbeit“ machen
    Mit einem M1 MacBook Air habe ich mehrere iOS-Apps gebaut und zwei Startup-Übernahmen durchlaufen
    Selbst 30–45 Minuten lange 4K-Rennvideos in FCP zu schneiden war kein Problem, und das Neo liefert sogar bessere Leistung als dieses Air

    • Früher habe ich auf einem gebrauchten Laptop mit norwegischer Tastatur ein PHP-Backend und ein jQuery-Frontend entwickelt
      Die damit gebauten Projekte haben mir meinen ersten Job als Entwickler eingebracht, und an dem Tag habe ich auch zum ersten Mal Hacker News kennengelernt
      Am Ende zählt nicht die Hardware, sondern die Umsetzungskraft
    • Im Urlaub habe ich statt eines Laptops mit einer Kombination aus Galaxy S22 + HDMI-Adapter + Bluetooth-Tastatur entwickelt
      Am Fernseher habe ich mit neovim und termux in Elixir entwickelt, und die Tests waren in 5 Sekunden durch
      Rust-Builds waren langsam, aber dank Portabilität und Batterieeffizienz war es trotzdem eine ziemlich angenehme Erfahrung
    • Ich nutze immer noch ein Intel MacBook Pro (16GB) von 2019
      Selbst wenn Xcode-Builds, Docker, Claude Code und Codex gleichzeitig laufen, hält es gut durch
      Allerdings ist das Lüftergeräusch auf Jet-Niveau, daher habe ich ein neues M5 Max 16" MBP (48GB) bestellt
      Ich upgrade etwa im 7-Jahres-Rhythmus, also wird es wohl auch diesmal lange halten
    • Ich habe ein Jahr lang iOS-Apps auf einem M1 Mac Mini (8GB) gebaut
      Während der Builds hat er etwas gestottert, und beim Wechsel zu Firefox war auch das Umschalten zwischen Tabs langsamer, aber es war absolut machbar
      Dieselbe Arbeit auf einem Intel MacBook Pro (16GB) lief deutlich flüssiger und angenehmer
      Gefühlt war der Unterschied bei der Reaktionsfähigkeit des OS groß
    • Menschen unterschätzen oft 8GB Arbeitsspeicher
      Dank komprimiertem Speicher passen realistisch 2- bis 3-mal mehr Daten hinein, und dank NVMe-SSD sind auch Swap-Lesezugriffe schnell
      Was mich tatsächlich eher stört, ist das fehlende Tastatur-Backlight

  • Beim Unterrichten teile ich Daten so ein — passt alles in den Speicher einer Maschine, ist es Small data, passt es auf die Platte, ist es Medium data, alles darüber ist Big data
    Beim Modernisieren einer 20 Jahre alten Python-App habe ich kürzlich das Backend so austauschbar gemacht, dass polars oder duckDB eingesetzt werden können, und die Geschwindigkeit wurde 40- bis 80-mal höher
    Diese Arbeit hat nur zwei Tage gedauert

    • Inzwischen kann man in ein einzelnes System auch 64TB DDR5 RAM stecken, daher ist heute fast alles Small data, solange es nicht Data-Lake-Größe erreicht
    • Mich würde interessieren, warum polars einen so großen Geschwindigkeitsunterschied gebracht hat
      Wenn man es richtig benutzt, ist es schnell, aber bei falscher Verwendung kann die Performance stark einbrechen
    • Ein Klassiker, aber immer noch relevant: Your Data Fits in RAM
      Teuer ist es zwar, aber die meisten Probleme passen immer noch in den RAM
    • Dank NVMe ist der Plattenzugriff schneller geworden, wodurch auch die Definition von „Medium data“ unschärfer geworden ist
      Big-Data-Infrastruktur im Stil der 2000er wirkt inzwischen veraltet

  • Als ich den DuckDB-Beitrag zu Mobile-Benchmarks gelesen habe, ist mein Vertrauen gesunken
    Eine Swift-App mit einer CLI-App zu vergleichen wirkte auf mich wie Äpfel mit Bananen vergleichen

    • Das Experiment bestand allerdings darin, auf Smartphones eine lokale CLI-App auszuführen
      Es war kein Vergleich zwischen iPhone und Android, sondern ein Vergleich mit einem System aus einer Forschungsarbeit zur vektorisierten Query-Verarbeitung

  • Das ist auch Kritik an der AWS-Compute-Performance

    • AWS nutzte EBS-Netzwerkspeicher, daher ist die Latenz viel höher als bei einem lokalen PCIe-Bus
      Gerade bei Random-Access-Lasten macht das einen großen Unterschied
    • War AWS trotzdem nicht schneller als ein Laptop?
      Nur weil die Netzwerkplatte langsam war, lässt sich AWS insgesamt schwer kritisieren
      AWS hat auch Instanzen mit lokaler SSD
    • Die Cloud ist aber weiterhin übertrieben teuer
      Mein M1 Max-Laptop schlägt die meisten Cloud-Instanzen deutlich
      Bei den Bandbreitenpreisen kann der Unterschied bis zum 10.000-Fachen gehen, und inzwischen kennt der Großteil der heutigen Entwicklergeneration nur noch Cloud-SaaS
      Ich habe diesen Wandel in Echtzeit beobachtet
    • Tatsächlich sagt der Artikel das Gegenteil
      „Wenn man jeden Tag Big-Data-Jobs auf dem Laptop macht, ist das Neo nicht geeignet“
      „Wenn man aber DuckDB in der Cloud laufen lässt und den Laptop als Client nutzt, ist es hervorragend“ — das war die Kernaussage

  • Ich bin ein armer Ökologe, aber auf diesem kleinen Computer kann ich meine gesamte Arbeit mit R und Word erledigen
    Für den Preis bin ich mit der hochwertigen Verarbeitungsqualität sehr zufrieden

    • Forschen Sie zufällig an Muscheln?
      Bei uns wurden leider die meisten staatlich geförderten Programme zur Muschelforschung eingestellt
    • Aber haben Sie es schon gekauft? Ich dachte, es sei noch in der Vorbestellungsphase

  • Ich mag DuckDB wirklich sehr
    Ich habe auf AWS Lambda einen PoC gemacht, der in S3 als GZ gespeicherte Daten verarbeitet,
    und damit 400 Zeilen C#-Code durch 10 Zeilen ersetzt
    Ein erstaunliches Open-Source-Tool

    • Ich halte es für eines der großartigsten Open-Source-Geschenke der letzten Jahre

  • Leute, die sagen „Was soll man 2026 noch mit 8GB anfangen“, sollten solche Beiträge unbedingt lesen

  • Ich wünschte, mehr Unternehmen würden solche Showcases zur Leistung gewöhnlicher Hardware machen
    Es ist nützlich zu sehen, welche Lasten realistisch bewältigt werden können

  • Für den Benchmark hätte man lokale NVMe-Instanzen (c8gd.4xlarge) verwenden sollen

    • Guter Hinweis, daher wurde tatsächlich noch einmal mit c8gd.4xlarge (950GB NVMe) und c5ad.4xlarge (RAID-0-Konfiguration) getestet
      Die Ergebnisse meines lokalen MacBook M1 Max (64GB, 10 Kerne) wurden ebenfalls zum Vergleich herangezogen
      Im Ergebnis war der M1 Max weiterhin schneller als die Cloud-Instanzen
      Mit einem aktuellen M5 Pro/Max dürfte der Abstand noch größer ausfallen
    • AWS-lokales NVMe ist allerdings flüchtiger Speicher, daher müssen die Daten jedes Mal vorab hochgeladen werden
      Für Benchmark-Zwecke ist das aber eher ideal
    • Unklar ist allerdings weiterhin, ob bei einem großflächigen Stromausfall in einer Region die Datenpersistenz garantiert ist
      Wer vollständige Haltbarkeit will, braucht nach wie vor WAL-Streaming

  • Gut war, dass sofort erkannt wurde, dass die Cloud-Instanz Netzwerkplatten nutzt
    Dann frage ich mich aber, warum nicht mit Instanzen mit lokalem Storage (c8id.2xlarge, c8id.4xlarge) erneut gebenchmarkt wurde
 
dkang 2026-03-14

Es wurde ein Kommentar gepostet, in dem gefragt wird, ob der verarmte Ökologe wegen seines Benutzernamens clamlady Muscheln erforscht (ich dachte, „Muschel“ sei eine Fehlübersetzung und habe deshalb nachgesehen, wie es im Original steht).