¿Por qué es tan rápido DuckDB? Almacenamiento columnar, ejecución vectorizada y diseño de un motor analítico moderno

DuckDB se ha convertido en los últimos tres años en una herramienta con la que cualquier persona que haga análisis de datos con Python se ha topado, directa o indirectamente. La integración sin copia con Pandas, Polars y PyArrow ha vuelto trivial ejecutar SQL sobre conjuntos de millones de filas. El nuevo artículo técnico destacado en Hacker News examina de cerca las tres decisiones de diseño que hacen tan rápido el motor.

Decisión uno: almacenamiento columnar. Las bases relacionales tradicionales (PostgreSQL, MySQL) guardan una fila dentro de un mismo bloque de disco. Las consultas analíticas suelen necesitar leer solo una o dos columnas. DuckDB guarda todos los datos columna a columna, de modo que una consulta analítica no tiene que leer las columnas que no necesita.

Decisión dos: ejecución vectorizada. Los motores tradicionales procesan la consulta fila a fila; un bucle for se ejecuta por separado para cada fila. DuckDB, en cambio, procesa lotes de 2048 filas: un vector. Esto encaja directamente con las instrucciones SIMD de los procesadores modernos; medias, sumas y comparaciones se ejecutan entre 4 y 16 veces más rápido.

Decisión tres: integración sin copia. Al trabajar con estructuras de datos existentes como Pandas o PyArrow, DuckDB no crea una copia de los datos, sino que apunta directamente a la zona de memoria. Para una base de datos clásica, el conjunto de datos normalmente debería escribirse antes en disco como CSV o Parquet y volverse a leer. DuckDB se salta ese paso y lee directamente la memoria de Python.

Al sumar estas tres decisiones, para una consulta analítica típica DuckDB es de 5 a 50 veces más rápido que PostgreSQL y, en general, de 10 a 100 veces más rápido que Pandas. Los benchmarks compartidos en el hilo de Hacker News muestran que, a escala de 100 millones de filas, DuckDB completa la consulta de agrupación habitual en cerca de un décimo del tiempo de PostgreSQL.

Otra característica arquitectónica importante es que la salida no está optimizada para escritura en disco. DuckDB se construye sobre un modelo que produce resultados de consulta analítica rápidamente en memoria y que se consumen sobre todo en el lado de Python. Es un diseño inadecuado para cargas OLTP, pero una ventaja para analítica.

El proyecto creció con raíces académicas open source. Empezó como un razonamiento en el grupo de bases de datos del CWI en los Países Bajos, se hizo público en 2019 y en 2026 forma parte de las pilas de análisis de datos de empresas como Goldman Sachs, Stripe, JP Morgan o Klaviyo.

La velocidad de DuckDB no proviene solo del almacenamiento columnar ni solo de la ejecución vectorizada; estas son técnicas bien conocidas. Lo que marca la diferencia es la aplicación conjunta de las tres decisiones y la integración profunda con el ecosistema moderno de datos de Python. DuckDB comparte un mundo de diseño con Apache Arrow y Polars, que aplican las mismas técnicas.

En cuanto a licencia, DuckDB se distribuye bajo licencia MIT, lo que elimina un obstáculo para la adopción empresarial. Para sustituir un proyecto de base de datos empresarial que Cloudera cerró el año pasado, muchas organizaciones adoptan DuckDB y lo incrustan directamente en sus herramientas internas de visualización.

Mensaje general: DuckDB se ha convertido en un nuevo valor por defecto para cargas analíticas pequeñas y medias. Poder procesar miles de millones de filas directamente dentro de un script de Python, sin necesidad de un «servidor de base de datos», es probablemente el avance analítico más práctico de los últimos años. El artículo de Hacker News recuerda que esa velocidad no está en una fórmula única, sino en el efecto compuesto de tres decisiones de diseño.