# warfield-duckdb-changing-physics-analytics-2026-08-26

## Veille

Gastbeitrag von **Andy Warfield**, Ingenieur im **S3**-Team bei **AWS**, veröffentlicht am **26. August 2026** auf *All Things Distributed*, dem Blog von **Werner Vogels**, der ihn mit wenigen Zeilen unter „--W" einleitet: **3.554 Wörter** laut Seitenangabe. Der Text dient als Vehikel für die Ankündigung, dass **DuckLabs**, das Team hinter **DuckDB**, zu **AWS** stößt. (A) Die These: In der Systeminformatik geht es darum, den eleganten Kompromiss gegenüber einer sich verändernden „Physik" zu suchen — den Verhältnissen zwischen Speichergeschwindigkeit, Netzwerk und Rechenleistung — und diese Physik hat sich verändert. Warfield beziffert die Kluft: eine **m1.xlarge** aus dem Jahr 2007 bot **15 GB RAM**, **4 virtuelle Kerne** und **~1 Gb/s** Netzwerk; eine **m8g.48xlarge** bietet heute etwa das **50-fache** in jeder der drei Dimensionen. Das Wachstum der Datensätze folgt derweil einer Verteilung, deren Schwanz aus sehr großen Volumina besteht. (B) Die Konsequenz: Verteilte Verarbeitung — **MapReduce**, die **RDDs** von **Spark** — wurde unter den I/O-Beschränkungen der frühen 2000er-Jahre entworfen, und ein Großteil der ihr zugewiesenen Arbeit muss die Anwendung nicht mehr verlassen. Daher die eingebettete, prozessinterne Bibliotheks-Engine, die im Adressraum der Anwendung läuft und für die **DuckDB** das Beispiel liefert. Warfield verankert dies im Paper *Scalability! But at what COST?* (2015) und im Epigraph von **Paul Barham**: „You can have a second computer once you've shown you know how to use the first one." Er formuliert einen expliziten Vorbehalt: „When a job genuinely needs a thousand machines, it needs a thousand machines." Der Korpus enthält bereits [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] vom selben Blog und [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] zu Self-Service-Analytics.

## Titre Article

DuckDB and the changing physics of analytics

## Date

2026-08-26

## URL

https://www.allthingsdistributed.com/2026/08/duckdb-and-the-changing-physics-of-analytics.html

## Keywords

DuckDB, DuckLabs, AWS-Übernahme, eingebettete analytische Engine, prozessinterne Bibliothek, sich verändernde Physik der Systeme, COST-Paper, Paul Barham, MapReduce, Spark RDD, verteilte Verarbeitung, MonetDB, X100, CWI, Vektorisierung, SQLite, S3 Tables, Apache Iceberg, Iceberg-Erweiterung v2 v3, asynchrone I/O, NIC-Auslastung, AWS Lambda, ATTACH, CONNECT, WebAssembly, glibc of structured data, DuckDB Foundation, MIT-Lizenz, m1.xlarge, m8g.48xlarge, Effizienz pro Kern, kontinuierliche Analytik

## Authors

Andy Warfield, ingénieur du service S3 chez AWS, en billet invité sur *All Things Distributed* ; introduction de Werner Vogels, CTO d'Amazon.

## Ton

Profil: Langform-Fachbeitrag in der ersten Person, im Register einer Ingenieurerzählung statt einer Pressemitteilung, mittleres bis hohes technisches Niveau, gerichtet an Entwickler und Architekten von Datensystemen. Der Aufbau bewegt sich von persönlicher Erinnerung zur Ankündigung: Eine Anekdote aus einem britischen Pub, in dem befreundete Physiker die Informatik verspotten — „jede Disziplin, die das Wort Wissenschaft in ihren Namen aufnehmen muss, ist wahrscheinlich keine Wissenschaft" — dient dazu, die These vorzubereiten, dass gerade dieses Fehlen einer unveränderlichen Wahrheit das Feld interessant macht. Es folgen drei zeitlich verortete Beispiele (das **NOW**-Projekt in Berkeley, die eigene Arbeit des Autors an **Xen**, die **MonetDB**/**X100**-Forschung am CWI), die Feststellung, dass diese Beschränkungen zyklisch wiederkehren — die Virtualisierungsideen von Xen waren bereits in den 1960er-Jahren auf IBM-Großrechnern angelegt — und anschließend die Anwendung auf die Datenverarbeitung. Warfield relativiert seine Sicht auf verteilte Systeme: „I mean this much more as an observation than as a criticism of these systems, because they were building for their own physics." Die Abschnittsüberschriften spielen mit dem Enten-Sprichwort (*If it walks like a duck… / …and quacks like a duck / …it must be a duck*), und die Anekdote von Hannes' Haustier-Ente Wilbur wird als Ursprung des Namens angegeben. Direkt zitierbar: die Formulierung „the glibc of structured data", die Aussage, dass „'analytics' is becoming less of a separate activity that happens to data somewhere else, and more of something you do continuously as you build", das berichtete Ziel von Hannes Mühleisen — „anyone to work with data confidently" zu ermöglichen — und der Satz aus dem SIGMOD-Paper über das Fehlen jeglicher revolutionärer Komponente in DuckDB.

## Pense-betes

- **Das Argument ist ein Verhältnis, kein Absolutwert**: Verschoben haben sich die Verhältnisse zwischen Rechenleistung, Speicher und Netzwerk auf einer einzelnen Maschine. Genannte Referenzpunkte: die m1.xlarge von 2007 (15 GB, 4 vCPUs, ~1 Gb/s) gegenüber der m8g.48xlarge (~50-fach auf allen drei Achsen); das MacBook Pro des Autors beansprucht das 3- bis 5-Fache an Kernen und RAM, ~40-fache Speicherbandbreite und mehr als das 100-Fache der I/O-Bandbreite der m1.xlarge. Ein Server übertrifft heute die Cluster, auf denen viele Menschen Hadoop und Spark betrieben.
- **Datenwachstum ist eine Verteilung, kein einheitlicher Trend.** Die größten Datensätze wachsen exponentiell, bilden aber den Schwanz; viele andere folgen menschlichen Größenordnungen — der Größe eines Unternehmens, seiner Kundenzahl, der Anzahl täglicher Banktransaktionen. Es ist die Lücke zwischen beiden, die das erneuerte Interesse an Single-Host-Engines antreibt.
- **Das COST-Paper als Referenzpunkt**: *Scalability! But at what COST?* (McSherry, Isard, Murray, 2015) vergleicht eine gut optimierte Einzelthread-Implementierung mit verteilten Frameworks bei denselben Aufgaben — bei Graphenverarbeitungs-Workloads schlägt der Einzelthread verteilte Systeme, die auf **128 Kernen** laufen, und es braucht **512 Kerne**, damit das verteilte System wieder die Führung übernimmt. Warfield weist darauf hin, dass die Autoren selbst an verteilten Systemen arbeiteten: Der Punkt sei Effizienz pro Kern, keine Ablehnung der Verteilung.
- **Was die „Bibliotheks"-Form verändert**: Die Engine läuft im Adressraum der Anwendung, auf bereits vorhandenen Speicherstrukturen, und kümmert sich ebenso um ihren eigenen Overhead wie um die ausgeführten Abfragen. Sie muss nicht beim Client sitzen — sie wird zu einer Komponente, die überall im Stack platziert werden kann, wo sie nützlich ist, bis hin zur Kompilierung zu **WebAssembly** und der Ausführung in einem Browser-Tab (shell.duckdb.org). Genannte Herkunft: Das SIGMOD-2019-Demo-Paper stützte sich auf die Popularität von **SQLite**, und die beiden Gründer kommen aus dem CWI-Labor, das MonetDB und X100 hervorbrachte.
- **Der Zeitverlauf AWS ↔ DuckLabs, wie berichtet**: AWS wird Kunde von DuckLabs und sponsert die **Iceberg**-Erweiterung während der Arbeit an **S3 Tables**, mit dem Ziel, Iceberg über die Spark-Welt hinaus zu erweitern; die Erweiterung deckt inzwischen die Spezifikationen **v2 und v3** ab und trieb die für Version **2.0** erwartete **asynchrone I/O** voran, deren Entwurfsziel es ist, die Netzwerkkarte beim Scannen von Tabellen auf S3 auszulasten. Die einzige Zahl des Artikels: mehr als **800.000 Downloads pro Woche** für die Erweiterung. Weitere genannte Ansätze: **Lambda** als Primitive zum Starten von Abfragen sowie die Befehle **ATTACH**/**CONNECT** in Richtung AWS-Engines.
- **Bedingungen des Deals**: DuckLabs stößt **als Tochtergesellschaft** zu AWS; das DuckDB-Projekt bleibt unter der Aufsicht der **DuckDB Foundation** quelloffen, entwickelt vom DuckLabs-Team unter der Lizenz **MIT**; das Team bleibt in Amsterdam. Hannes Mühleisen und Mark Raasveldt erläutern ihre Beweggründe in einem separaten, hier nicht behandelten Beitrag im DuckLabs-Blog. AWS erklärt, sich an Entwickler „und zunehmend an Agenten" zu richten, und gibt an, DuckDB bereits intern für Dashboards, CLI-Tools, serverseitige Beschleuniger und Brücken zwischen Systemen zu nutzen.
- ⚠️ **Was der Text nicht liefert**: keinen Betrag oder keine finanzielle Struktur des Deals, keine vergleichenden Leistungsdaten zu DuckDB selbst und keine quantifizierten Governance-Details zur Foundation (Zusammensetzung, Rechte, Laufzeitverpflichtungen). Der einzige quantifizierte Referenzpunkt des Beitrags bleibt das Download-Volumen der Erweiterung.
- **Verwandt**: [[netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12]] zu einem einzigen, von mehreren Engines konsumierten Datenmodell, und [[clouded-judgement-121225-long-live]] zur Wertverschiebung hin zu Systems of Record.

## RésuméDe400mots

Andy Warfield, Ingenieur im S3-Team bei AWS, veröffentlichte am 26. August 2026 einen Gastbeitrag auf All Things Distributed, eingeleitet von Werner Vogels. Darin erklärt er, warum eingebettete analytische Engines wie DuckDB an Bedeutung gewinnen, und kündigt an, dass DuckLabs, das Team hinter der Entwicklung von DuckDB, zu AWS stößt.

Sein Deutungsraster ist das einer sich verändernden „Physik". Während die Naturwissenschaften Invarianten erforschen, sucht die Systeminformatik den eleganten Kompromiss gegenüber Verhältnissen, die sich verschieben: Speichergeschwindigkeit gegenüber Netzwerkgeschwindigkeit, Reichhaltigkeit der Abstraktionen gegenüber verfügbarer Leistung. Er zitiert drei Momente — das NOW-Projekt in Berkeley, seine eigene Arbeit an Xen sowie die Forschung zu MonetDB und X100 am Amsterdamer CWI, wo sich der Engpass der Abfrageverarbeitung von der Festplatte zur CPU verschoben hatte — und stellt fest, dass diese Beschränkungen zyklisch wiederkehren.

Auf Daten angewendet, erklärt dieses Raster die verteilte Verarbeitung. Verarbeitung ist auf einer einzelnen schnellen Maschine immer einfacher und effizienter, aber wenn die Festplatte oder Netzwerkkarte eines Servers das gewünschte Volumen nicht mehr lesen kann, wird partitioniert. Das war die Beschränkung der frühen 2000er-Jahre, die MapReduce und später die RDDs von Spark hervorbrachte. Warfield hebt zwei Eigenschaften dieser Systeme hervor: Sie innovierten stark bei der Entwicklerergonomie und akzeptierten einen festen Kosten für Planung und Verteilung, wobei sie auf den durch das Hinzufügen von Maschinen gewonnenen Durchsatz setzten statt auf Effizienz pro Einheit.

Doch die Verhältnisse haben sich verändert. Eine aktuelle Instanz bietet etwa das Fünfzigfache an Speicher, Kernen und Netzwerkbandbreite der größten EC2-Instanz von 2007, während das Wachstum der Datensätze einer Verteilung folgt, deren Extremfälle den Schwanz bilden. Das Paper Scalability! But at what COST? von 2015 hatte bereits gezeigt, dass eine sorgfältig optimierte Einzelthread-Implementierung verteilte Frameworks schlagen konnte, die auf hundertachtundzwanzig Kernen liefen.

DuckDB, 2018 von Hannes Mühleisen und Mark Raasveldt lanciert, wendet diese Logik an: eine analytische Bibliotheks-Engine, die prozessintern im Adressraum der Anwendung läuft und dem Vertriebsmodell von SQLite folgt. AWS wurde Kunde von DuckLabs und anschließend Sponsor der Iceberg-Erweiterung, parallel zu seiner Arbeit an S3 Tables; die Erweiterung unterstützt inzwischen Iceberg v2 und v3 und überschreitet 800.000 Downloads pro Woche.

Warfield präsentiert das eingebettete Modell nicht als Ersatz: Wenn ein Job tausend Maschinen benötigt, benötigt er sie. Was sich ändere, schreibt er, sei, dass ein Großteil der an Daten geleisteten Arbeit tatsächlich nie einen Cluster benötigt hatte. DuckLabs stößt als Tochtergesellschaft zu AWS, wobei das Projekt unter der MIT-Lizenz und unter der Aufsicht der DuckDB Foundation quelloffen bleibt.

## GrapheDeConnaissance

- Andy Warfield —a_créé→ DuckDB and the changing physics of analytics (DOCUMENT, 0.97)
- Werner Vogels —publie→ DuckDB and the changing physics of analytics (DOCUMENT, 0.93)
- Andy Warfield —travaille_chez→ AWS (ORGANISATION, 0.96)
- AWS —collabore_avec→ DuckLabs (ORGANISATION, 0.97)
- DuckLabs —fait_partie_de→ AWS (ORGANISATION, 0.96)
- Hannes Mühleisen —a_créé→ DuckDB (TECHNOLOGIE, 0.97)
- Mark Raasveldt —a_créé→ DuckDB (TECHNOLOGIE, 0.97)
- DuckDB —est_instance_de→ moteur analytique embarqué (CONCEPT, 0.95)
- DuckDB —s_inspire_de→ SQLite (TECHNOLOGIE, 0.92)
- DuckDB —est_basé_sur→ MonetDB (TECHNOLOGIE, 0.87)
- DuckDB Foundation —permet→ maintien de DuckDB en open source sous licence MIT après l'entrée de DuckLabs chez AWS (AFFIRMATION, 0.94)
- Andy Warfield —affirme_que→ les rapports entre calcul, mémoire et réseau sur une seule machine ne sont plus les contraintes qu'ils étaient (AFFIRMATION, 0.95)
- m8g.48xlarge —mesure→ environ 50× la mémoire, les cœurs et la bande passante réseau d'une m1.xlarge de 2007 (15 Go, 4 vCPU, ~1 Gb/s) (MESURE, 0.93)
- Andy Warfield —affirme_que→ la croissance des jeux de données suit une distribution dont les très grands volumes sont la queue, beaucoup d'autres suivant des grandeurs humaines (AFFIRMATION, 0.9)
- MapReduce —résout→ contrainte de bande passante d'I/O des grands jeux de données du début des années 2000 (CONCEPT, 0.93)
- Spark —utilise→ Resilient Distributed Datasets (CONCEPT, 0.94)
- Scalability! But at what COST? —mesure→ une implémentation mono-thread optimisée bat des systèmes de graphe distribués sur 128 cœurs, le distribué ne repassant devant qu'à 512 cœurs (MESURE, 0.93)
- Paul Barham —affirme_que→ « You can have a second computer once you've shown you know how to use the first one » (CITATION, 0.94)
- moteur analytique embarqué —réduit→ surcoût de planification, d'expédition de tâches et d'aller-retour réseau du traitement distribué (CONCEPT, 0.9)
- Andy Warfield —affirme_que→ l'embarqué ne remplace pas le distribué : un travail qui exige mille machines les exige toujours (AFFIRMATION, 0.94)
- extension Iceberg de DuckDB —mesure→ plus de 800 000 téléchargements par semaine (MESURE, 0.92)
- extension Iceberg de DuckDB —utilise→ Apache Iceberg (TECHNOLOGIE, 0.95)
- DuckDB —s_applique_à→ S3 Tables (TECHNOLOGIE, 0.93)
- S3 Tables —fait_partie_de→ S3 (TECHNOLOGIE, 0.95)
- I/O asynchrone —permet→ saturer le NIC lors du scan de tables stockées sur S3, attendu en DuckDB 2.0 (AFFIRMATION, 0.9)
- DuckDB —s_applique_à→ WebAssembly (TECHNOLOGIE, 0.91)
- Andy Warfield —affirme_que→ DuckDB est « the glibc of structured data » : une dépendance sobre et ubiquitaire à laquelle beaucoup de logiciels se lient sans y penser (CITATION, 0.92)
- Andy Warfield —prédit→ l'analytique cesse d'être une activité séparée pour devenir quelque chose que l'on fait en continu pendant qu'on construit (AFFIRMATION, 0.9)
- AWS —utilise→ DuckDB en interne pour des tableaux de bord, de l'outillage CLI, des accélérateurs côté serveur et des ponts entre systèmes (AFFIRMATION, 0.89)
- Xen —s_inspire_de→ virtualisation des mainframes IBM des années 60 (CONCEPT, 0.88)

---
Canonical: https://www.thekb.eu/de/fiches/warfield-duckdb-changing-physics-analytics-2026-08-26/