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

## Veille

Artículo de invitado de **Andy Warfield**, ingeniero del equipo de **S3** en **AWS**, publicado el **26 de agosto de 2026** en *All Things Distributed*, el blog de **Werner Vogels**, quien lo presenta en unas líneas firmadas «--W»: **3554 palabras** según la página. El texto sirve de vehículo para el anuncio de que **DuckLabs**, el equipo detrás de **DuckDB**, se incorpora a **AWS**. (A) La tesis: la informática de sistemas consiste en buscar el compromiso elegante frente a una «física» cambiante —las proporciones entre velocidad de memoria, red y cómputo— y esa física ha cambiado. Warfield cuantifica la brecha: una **m1.xlarge** de 2007 ofrecía **15 GB de RAM**, **4 núcleos virtuales** y **~1 Gb/s** de red; una **m8g.48xlarge** actual ofrece aproximadamente **50×** más en cada uno de los tres aspectos. El crecimiento de los conjuntos de datos, por su parte, sigue una distribución cuya cola está formada por volúmenes muy grandes. (B) La consecuencia: el procesamiento distribuido —**MapReduce**, los **RDD** de **Spark**— se diseñó bajo las restricciones de E/S de principios de la década de 2000, y buena parte del trabajo que se le asignaba ya no necesita salir de la aplicación. De ahí el motor embebido, de tipo biblioteca en proceso, que se ejecuta en el espacio de direcciones de la aplicación, del que **DuckDB** es el ejemplo. Warfield ancla esto en el artículo *Scalability! But at what COST?* (2015) y en el epígrafe de **Paul Barham**: «Puedes tener una segunda computadora una vez que hayas demostrado que sabes usar la primera.» Formula una salvedad explícita: «Cuando un trabajo realmente necesita mil máquinas, necesita mil máquinas.» El corpus ya contiene [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] del mismo blog y [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sobre analítica de autoservicio.

## 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, adquisición de AWS, motor analítico embebido, biblioteca en proceso, física cambiante de los sistemas, artículo COST, Paul Barham, MapReduce, RDD de Spark, procesamiento distribuido, MonetDB, X100, CWI, vectorización, SQLite, S3 Tables, Apache Iceberg, extensión Iceberg v2 v3, E/S asíncrona, saturación de la NIC, AWS Lambda, ATTACH, CONNECT, WebAssembly, glibc de los datos estructurados, DuckDB Foundation, licencia MIT, m1.xlarge, m8g.48xlarge, eficiencia por núcleo, analítica 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

Perfil: artículo técnico extenso en primera persona, en el registro de la narrativa de un ingeniero más que de un comunicado de prensa, nivel técnico medio-alto, dirigido a desarrolladores y arquitectos de sistemas de datos. La estructura pasa del recuerdo personal al anuncio: una anécdota de un pub británico en el que unos amigos físicos se burlan de la informática —«cualquier disciplina que necesite poner 'ciencia' en su nombre probablemente no sea una ciencia»— se usa para plantear la tesis de que esta ausencia de una verdad inmutable es precisamente lo que hace interesante al campo. Siguen tres ejemplos situados en el tiempo (el proyecto NOW de Berkeley, el propio trabajo del autor en Xen, la investigación sobre MonetDB/X100 en el CWI), la observación de que estas restricciones reaparecen en ciclos —las ideas de virtualización de Xen ya se habían planteado en los mainframes de IBM en la década de 1960— y luego la aplicación al procesamiento de datos. Warfield matiza su lectura de los sistemas distribuidos: «Lo digo mucho más como una observación que como una crítica a estos sistemas, porque estaban construyendo para su propia física.» Los títulos de las secciones desarrollan el proverbio del pato (Si camina como un pato… / …y grazna como un pato / …debe de ser un pato), y la anécdota del pato mascota de Hannes, Wilbur, se ofrece como el origen del nombre. Citas directamente aprovechables: la frase «la glibc de los datos estructurados», la afirmación de que «'analytics' está dejando de ser una actividad separada que le ocurre a los datos en otro lugar, y se está convirtiendo más en algo que se hace continuamente mientras se construye», el objetivo declarado de Hannes Mühleisen —permitir que «cualquiera pueda trabajar con datos con confianza»— y la frase del artículo de SIGMOD sobre la ausencia de cualquier componente revolucionario en DuckDB.

## Pense-betes

- **El argumento es una proporción, no un valor absoluto**: lo que ha cambiado son las proporciones entre cómputo, memoria y red en una sola máquina. Puntos de referencia dados: la m1.xlarge de 2007 (15 GB, 4 vCPU, ~1 Gb/s) frente a la m8g.48xlarge (~50× en los tres ejes); el MacBook Pro del autor afirma tener de 3 a 5× los núcleos y la RAM, ~40× el ancho de banda de memoria, y más de 100× el ancho de banda de E/S de la m1.xlarge. Un servidor actual supera a los clústeres en los que mucha gente ejecutaba Hadoop y Spark.
- **El crecimiento de los datos es una distribución, no una tendencia uniforme.** Los conjuntos de datos más grandes crecen exponencialmente, pero forman la cola; muchos otros siguen magnitudes a escala humana —el tamaño de una empresa, su número de clientes, el número de transacciones bancarias diarias—. Es la brecha entre ambos la que alimenta el renovado interés por los motores de un solo host.
- **El artículo COST como punto de referencia**: *Scalability! But at what COST?* (McSherry, Isard, Murray, 2015) compara una implementación de un solo hilo bien optimizada con marcos distribuidos en las mismas tareas — en cargas de trabajo de procesamiento de grafos, el hilo único supera a los sistemas distribuidos que se ejecutan en **128 núcleos**, y hacen falta **512 núcleos** para que el sistema distribuido vuelva a tomar la delantera. Warfield señala que los propios autores trabajaban en sistemas distribuidos: el punto es la eficiencia por núcleo, no un rechazo de la distribución.
- **Lo que cambia la forma de «biblioteca»**: el motor se ejecuta en el espacio de direcciones de la aplicación, sobre estructuras de memoria ya presentes, y le preocupa tanto su propia sobrecarga como las consultas que ejecuta. No tiene que residir en el cliente: se convierte en un componente que puede colocarse donde sea útil en la pila, hasta el punto de compilarse a **WebAssembly** y ejecutarse en una pestaña del navegador (shell.duckdb.org). Filiación reivindicada: el artículo de demostración de SIGMOD 2019 se apoyaba en la popularidad de **SQLite**, y los dos fundadores provienen del laboratorio CWI que produjo MonetDB y X100.
- **La cronología AWS ↔ DuckLabs, según lo reportado**: AWS se convierte en cliente de DuckLabs y patrocina la extensión **Iceberg** durante el trabajo sobre **S3 Tables**, con el objetivo de extender Iceberg más allá del mundo Spark; la extensión ahora cubre las especificaciones **v2 y v3** y impulsó la **E/S asíncrona** prevista para la versión **2.0**, cuyo objetivo de diseño es saturar la NIC mientras se escanean tablas en S3. La única cifra del artículo: más de **800 000 descargas semanales** para la extensión. Otras vías mencionadas: **Lambda** como primitiva para lanzar consultas, y los comandos **ATTACH**/**CONNECT** hacia los motores de AWS.
- **Términos del acuerdo**: DuckLabs se incorpora a AWS **como subsidiaria**; el proyecto DuckDB sigue siendo de código abierto bajo la tutela de la **DuckDB Foundation**, desarrollado por el equipo de DuckLabs, bajo la licencia **MIT**; el equipo permanece en Ámsterdam. Hannes Mühleisen y Mark Raasveldt explican sus razones en una entrada aparte en el blog de DuckLabs, no cubierta aquí. AWS declara que se dirige a los desarrolladores «y cada vez más a agentes», y afirma que ya usa DuckDB internamente para paneles de control, herramientas de línea de comandos, aceleradores del lado del servidor y puentes entre sistemas.
- ⚠️ **Lo que el texto no proporciona**: ningún monto ni estructura financiera del acuerdo, ningún dato comparativo de rendimiento sobre el propio DuckDB, y ningún detalle cuantificado de la gobernanza de la Foundation (composición, derechos, compromisos de mandato). El único punto de referencia cuantificado del artículo sigue siendo el volumen de descargas de la extensión.
- **Relacionado**: [[netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12]] sobre un modelo de datos único consumido por múltiples motores, y [[clouded-judgement-121225-long-live]] sobre el desplazamiento del valor hacia los sistemas de registro.

## RésuméDe400mots

Andy Warfield, ingeniero del equipo de S3 en AWS, publicó un artículo de invitado en All Things Distributed el 26 de agosto de 2026, presentado por Werner Vogels. En él explica por qué los motores analíticos embebidos como DuckDB están cobrando importancia, y anuncia que DuckLabs, el equipo que desarrolla DuckDB, se incorpora a AWS.

Su marco de lectura es el de una «física» cambiante. Donde las ciencias físicas exploran invariantes, la informática de sistemas busca el compromiso elegante frente a proporciones que se desplazan: velocidad de memoria frente a velocidad de red, riqueza de las abstracciones frente a la potencia disponible. Cita tres momentos —el proyecto NOW de Berkeley, su propio trabajo en Xen, y la investigación sobre MonetDB y X100 en el CWI de Ámsterdam, donde el cuello de botella del procesamiento de consultas había pasado del disco a la CPU— y señala que estas restricciones reaparecen en ciclos.

Aplicado a los datos, este marco explica el procesamiento distribuido. El procesamiento siempre es más simple y eficiente en una sola máquina rápida, pero cuando el disco o la tarjeta de red de un servidor ya no puede leer el volumen deseado, se particiona. Esa fue la restricción de principios de la década de 2000, la que produjo MapReduce y luego los RDD de Spark. Warfield señala dos cualidades de estos sistemas: innovaron mucho en la ergonomía para el desarrollador, y aceptaron un costo fijo de planificación y distribución, apostando por el rendimiento ganado al añadir máquinas en lugar de por la eficiencia por unidad.

Pero las proporciones han cambiado. Una instancia actual ofrece aproximadamente cincuenta veces más memoria, núcleos y ancho de banda de red que la mayor instancia EC2 de 2007, mientras que el crecimiento de los conjuntos de datos sigue una distribución cuyos casos extremos forman la cola. El artículo Scalability! But at what COST? de 2015 ya había demostrado que una implementación de un solo hilo cuidadosamente optimizada podía superar a los marcos distribuidos que se ejecutaban en ciento veintiocho núcleos.

DuckDB, lanzado en 2018 por Hannes Mühleisen y Mark Raasveldt, aplica esta lógica: un motor analítico de tipo biblioteca en proceso, que se ejecuta en el espacio de direcciones de la aplicación, siguiendo el modelo de distribución de SQLite. AWS se convirtió en cliente de DuckLabs y luego en patrocinador de la extensión Iceberg de DuckDB, junto con su trabajo en S3 Tables; la extensión ahora es compatible con Iceberg v2 y v3 y supera las 800 000 descargas semanales.

Warfield no presenta el modelo embebido como un reemplazo: cuando un trabajo requiere mil máquinas, las requiere. Lo que está cambiando, escribe, es que buena parte del trabajo que se hace con datos en realidad nunca necesitó un clúster. DuckLabs se incorpora a AWS como subsidiaria, y el proyecto sigue siendo de código abierto bajo la licencia MIT y bajo la tutela de la 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/es/fiches/warfield-duckdb-changing-physics-analytics-2026-08-26/