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

## Veille

Guest post di **Andy Warfield**, ingegnere nel team **S3** di **AWS**, pubblicato il **26 agosto 2026** su *All Things Distributed*, il blog di **Werner Vogels**, che lo introduce in poche righe firmate «--W» : **3.554 parole** secondo la pagina. Il testo funge da veicolo per l'annuncio secondo cui **DuckLabs**, il team dietro **DuckDB**, entra a far parte di **AWS**. (A) La tesi: l'informatica dei sistemi consiste nel ricercare il compromesso elegante rispetto a una «fisica» mobile — i rapporti tra velocità della memoria, rete e calcolo — e quella fisica è cambiata. Warfield quantifica lo scarto: un **m1.xlarge** del 2007 offriva **15 GB di RAM**, **4 core virtuali** e **~1 Gb/s** di rete; un **m8g.48xlarge** oggi offre circa **50×** in più su ciascuno dei tre parametri. La crescita dei dataset, nel frattempo, segue una distribuzione la cui coda è costituita da volumi molto grandi. (B) La conseguenza: l'elaborazione distribuita — **MapReduce**, gli **RDD** di **Spark** — è stata concepita sotto i vincoli di I/O dei primi anni 2000, e gran parte del lavoro ad essa affidato non ha più bisogno di uscire dall'applicazione. Da qui il motore-libreria incorporato, in-process, che gira nello spazio di indirizzamento dell'applicazione, di cui **DuckDB** è l'esempio. Warfield àncora questo al paper *Scalability! But at what COST?* (2015) e all'epigrafe di **Paul Barham**: «Puoi avere un secondo computer una volta dimostrato di saper usare il primo.» Formula una riserva esplicita: «Quando un lavoro ha davvero bisogno di mille macchine, ha bisogno di mille macchine.» Il corpus contiene già [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] dallo stesso blog e [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sull'analytics self-service.

## 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, acquisizione AWS, motore analitico incorporato, libreria in-process, fisica dei sistemi in cambiamento, paper COST, Paul Barham, MapReduce, Spark RDD, elaborazione distribuita, MonetDB, X100, CWI, vettorizzazione, SQLite, S3 Tables, Apache Iceberg, estensione Iceberg v2 v3, I/O asincrono, saturazione NIC, AWS Lambda, ATTACH, CONNECT, WebAssembly, glibc dei dati strutturati, DuckDB Foundation, licenza MIT, m1.xlarge, m8g.48xlarge, efficienza per core, analytics continua

## 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

Profilo: post tecnico in prima persona, long-form, nel registro del racconto di un ingegnere più che di un comunicato stampa, livello tecnico medio-alto, rivolto a sviluppatori e architetti di sistemi dati. La struttura si muove dal ricordo personale all'annuncio: un aneddoto ambientato in un pub britannico dove amici fisici deridono l'informatica — «qualsiasi disciplina che ha bisogno di mettere "scienza" nel proprio nome probabilmente non è una scienza» — viene usato per porre la tesi secondo cui questa assenza di una verità immutabile è proprio ciò che rende interessante il campo. Seguono tre esempi collocati nel tempo (il progetto NOW di Berkeley, il lavoro dell'autore stesso su Xen, la ricerca su MonetDB/X100 al CWI), l'osservazione che questi vincoli si ripresentano ciclicamente — le idee di virtualizzazione di Xen erano già state delineate sui mainframe IBM negli anni '60 — e poi l'applicazione all'elaborazione dei dati. Warfield sfuma la sua lettura dei sistemi distribuiti: «Lo intendo molto più come un'osservazione che come una critica a questi sistemi, perché stavano costruendo per la propria fisica.» I titoli delle sezioni giocano sul proverbio dell'anatra (Se cammina come un'anatra… / …e starnazza come un'anatra / …deve essere un'anatra), e l'aneddoto dell'anatra domestica di Hannes, Wilbur, viene dato come origine del nome. Direttamente citabili: la frase «la glibc dei dati strutturati», l'affermazione secondo cui «'analytics' sta diventando sempre meno un'attività separata che accade ai dati altrove, e sempre più qualcosa che si fa in continuo mentre si costruisce», l'obiettivo dichiarato di Hannes Mühleisen — permettere «a chiunque di lavorare con i dati con sicurezza» — e la frase del paper SIGMOD sull'assenza di qualsiasi componente rivoluzionario in DuckDB.

## Pense-betes

- **L'argomento è un rapporto, non un valore assoluto**: ciò che è cambiato sono i rapporti tra calcolo, memoria e rete su una singola macchina. Punti di riferimento forniti: l'm1.xlarge del 2007 (15 GB, 4 vCPU, ~1 Gb/s) contro l'm8g.48xlarge (~50× su tutti e tre gli assi); il MacBook Pro dell'autore rivendica 3-5× i core e la RAM, ~40× la banda della memoria, e oltre 100× la banda di I/O dell'm1.xlarge. Un server odierno supera i cluster su cui molte persone eseguivano Hadoop e Spark.
- **La crescita dei dati è una distribuzione, non una tendenza uniforme.** I dataset più grandi crescono esponenzialmente, ma formano la coda; molti altri seguono grandezze a scala umana — la dimensione di un'azienda, il suo numero di clienti, il numero di transazioni bancarie giornaliere. È lo scarto tra i due a alimentare il rinnovato interesse per i motori a host singolo.
- **Il paper COST come punto di riferimento**: *Scalability! But at what COST?* (McSherry, Isard, Murray, 2015) confronta un'implementazione single-thread ben ottimizzata con framework distribuiti sugli stessi compiti — su carichi di elaborazione di grafi, il single thread batte i sistemi distribuiti eseguiti su **128 core**, e servono **512 core** perché il sistema distribuito riprenda il vantaggio. Warfield fa notare che gli stessi autori lavoravano su sistemi distribuiti: il punto è l'efficienza per core, non un rifiuto della distribuzione.
- **Cosa cambia la forma «libreria»**: il motore gira nello spazio di indirizzamento dell'applicazione, su strutture di memoria già presenti, e si preoccupa tanto del proprio overhead quanto delle query che esegue. Non deve necessariamente risiedere nel client — diventa un componente che può essere collocato ovunque sia utile nello stack, fino a compilare in **WebAssembly** ed essere eseguito in una scheda del browser (shell.duckdb.org). Filiazione rivendicata: il demo paper SIGMOD 2019 faceva leva sulla popolarità di **SQLite**, e i due fondatori provengono dal laboratorio CWI che ha prodotto MonetDB e X100.
- **La cronologia AWS ↔ DuckLabs, così come riportata**: AWS diventa cliente di DuckLabs e sponsorizza l'estensione **Iceberg** durante il lavoro su **S3 Tables**, con l'obiettivo di estendere Iceberg oltre il mondo Spark; l'estensione ora copre le specifiche **v2 e v3** e ha guidato l'**I/O asincrono** previsto nella versione **2.0**, il cui obiettivo di design è saturare la NIC durante la scansione delle tabelle su S3. L'unica cifra dell'articolo: oltre **800.000 download a settimana** per l'estensione. Altre piste menzionate: **Lambda** come primitiva per lanciare query, e i comandi **ATTACH**/**CONNECT** verso i motori AWS.
- **Termini dell'accordo**: DuckLabs entra in AWS **come filiale**; il progetto DuckDB resta open source sotto la governance della **DuckDB Foundation**, sviluppato dal team DuckLabs, sotto licenza **MIT**; il team resta ad Amsterdam. Hannes Mühleisen e Mark Raasveldt spiegano le loro motivazioni in un post separato sul blog di DuckLabs, non trattato qui. AWS dichiara di rivolgersi agli sviluppatori «e sempre più agli agenti», e afferma di usare già DuckDB internamente per dashboard, strumenti CLI, acceleratori lato server e ponti tra sistemi.
- ⚠️ **Ciò che il testo non fornisce**: nessun importo o struttura finanziaria dell'accordo, nessun dato di performance comparativo su DuckDB stesso, e nessun dettaglio di governance quantificato per la Foundation (composizione, diritti, impegni di durata). L'unico punto di riferimento quantificato del post resta il volume di download dell'estensione.
- **Correlati**: [[netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12]] su un modello di dati unico consumato da più motori, e [[clouded-judgement-121225-long-live]] sullo spostamento di valore verso i sistemi di record.

## RésuméDe400mots

Andy Warfield, ingegnere nel team S3 di AWS, ha pubblicato un guest post su All Things Distributed il 26 agosto 2026, introdotto da Werner Vogels. Nel testo, spiega perché i motori analitici incorporati come DuckDB stanno guadagnando importanza, e annuncia che DuckLabs, il team che sviluppa DuckDB, entra a far parte di AWS.

La sua griglia di lettura è quella di una «fisica» mobile. Laddove le scienze fisiche esplorano invarianti, l'informatica dei sistemi ricerca il compromesso elegante rispetto a rapporti che si spostano: velocità della memoria contro velocità della rete, ricchezza delle astrazioni contro potenza disponibile. Cita tre momenti — il progetto NOW di Berkeley, il proprio lavoro su Xen, e la ricerca su MonetDB e X100 al CWI di Amsterdam, dove il collo di bottiglia dell'elaborazione delle query si era spostato dal disco alla CPU — e osserva che questi vincoli si ripresentano ciclicamente.

Applicata ai dati, questa griglia spiega l'elaborazione distribuita. L'elaborazione è sempre più semplice ed efficiente su un'unica macchina veloce, ma quando il disco o la scheda di rete di un server non riescono più a leggere il volume desiderato, si partiziona. Era questo il vincolo dei primi anni 2000, quello che ha prodotto MapReduce e poi gli RDD di Spark. Warfield rileva due qualità di questi sistemi: hanno innovato molto sull'ergonomia per gli sviluppatori, e hanno accettato un costo fisso di pianificazione e distribuzione, scommettendo sul throughput ottenuto aggiungendo macchine piuttosto che sull'efficienza per unità.

Ma i rapporti sono cambiati. Un'istanza attuale offre circa cinquanta volte la memoria, i core e la banda di rete della più grande istanza EC2 del 2007, mentre la crescita dei dataset segue una distribuzione i cui casi estremi ne formano la coda. Il paper del 2015 Scalability! But at what COST? aveva già dimostrato che un'implementazione single-thread accuratamente ottimizzata poteva battere framework distribuiti eseguiti su centoventotto core.

DuckDB, lanciato nel 2018 da Hannes Mühleisen e Mark Raasveldt, applica questa logica: un motore analitico a libreria in-process, che gira nello spazio di indirizzamento dell'applicazione, seguendo il modello di distribuzione di SQLite. AWS è diventata cliente di DuckLabs e poi sponsor dell'estensione Iceberg, parallelamente al proprio lavoro su S3 Tables; l'estensione ora supporta Iceberg v2 e v3 e supera 800.000 download a settimana.

Warfield non presenta il modello incorporato come una sostituzione: quando un lavoro richiede mille macchine, le richiede. Ciò che sta cambiando, scrive, è che gran parte del lavoro svolto sui dati in realtà non ha mai avuto bisogno di un cluster. DuckLabs entra in AWS come filiale, con il progetto che resta open source sotto licenza MIT e sotto la governance della DuckDB Foundation.

## 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/it/fiches/warfield-duckdb-changing-physics-analytics-2026-08-26/