Por qué DuckDB es tan rápido por dentro

Si trabajas con analítica y todavía te toca pelear con consultas que tardan demasiado, DuckDB seguramente ya apareció en tu radar. No es raro: se está metiendo en dashboards, notebooks, pipelines locales y herramientas embebidas porque da respuestas muy rápidas sin pedirte que montes un cluster entero.

La pregunta útil no es solo “¿es rápido?”, sino “¿por qué lo es por dentro?”. Cuando entiendes su arquitectura, ves mejor cuándo te conviene más que Postgres para analítica, qué límites tiene y qué decisiones de diseño sí vale la pena copiar en otros proyectos.

Qué problema resuelve DuckDB

DuckDB no nació para reemplazar a Postgres como base de datos transaccional. Su foco es otro: analítica local, consultas SQL sobre archivos o datasets en memoria y ejecución eficiente en una sola máquina. Eso cambia casi todo, desde el optimizador hasta la forma de leer datos.

En la práctica, esto importa porque muchos equipos en Latinoamérica no necesitan levantar un warehouse para cada análisis. A veces solo quieres leer un CSV de 8 GB, cruzarlo con otra tabla, sacar agregaciones y entregar un resultado en segundos, no en minutos. Ahí DuckDB encaja muy bien.

También encaja cuando quieres analítica embebida dentro de una app. Por ejemplo, una herramienta interna de finanzas, un notebook de ciencia de datos o un producto SaaS que permite consultas ad hoc sobre datos del cliente. En esos casos, la latencia de preparación pesa tanto como la de ejecución.

El tipo de carga que le queda cómoda

DuckDB brilla cuando la consulta hace bastante lectura, filtrado, agregación y joins sobre datos tabulares. No necesita muchas escrituras concurrentes ni transacciones pesadas. Su objetivo es exprimir una sola máquina y usar bien CPU, memoria y caché.

Por eso suele sentirse ágil en escenarios como estos:

1. Exploración de datos en CSV, Parquet o JSON ya estructurado.
2. Agregaciones sobre millones de filas con pocos usuarios concurrentes.
3. Transformaciones SQL dentro de notebooks, scripts o servicios backend.
4. Consultas analíticas sobre datos externos sin cargarlos primero a una base tradicional.

Si tu caso depende de cientos de escrituras por segundo, bloqueo fino y muchas conexiones concurrentes, Postgres sigue siendo una mejor base generalista. DuckDB no compite ahí; compite en otra liga.

La idea central: ejecución vectorizada

Una de las razones más importantes de su velocidad es que DuckDB no procesa fila por fila como muchos motores clásicos. Usa ejecución vectorizada, o sea, trabaja con lotes de datos en bloques relativamente pequeños. Eso reduce overhead y aprovecha mejor la CPU.

La lógica es simple: en vez de llamar a una función por cada fila, el motor toma un vector de valores y aplica la operación sobre todo el bloque. Menos llamadas, menos saltos, mejor uso de caché. En hardware moderno, eso se nota mucho.

Este enfoque no es mágico, pero sí muy eficiente para analítica. Cuando haces un WHERE, un GROUP BY o un join, el motor puede procesar miles de valores por lote y mantener un flujo más predecible para el procesador.

Por qué eso pega en CPU y memoria

La CPU moderna odia los patrones impredecibles. Si tu motor salta de una fila a otra, toca estructuras dispersas y hace demasiadas llamadas pequeñas, desperdicia ciclos. DuckDB intenta reducir ese costo con bloques compactos y operaciones sobre vectores.

Además, los datos en bloque ayudan a la localidad de caché. Si el motor trabaja con columnas y lotes pequeños, tiene más chances de mantener en caché los valores que realmente necesita. Eso es especialmente útil en agregaciones y filtros repetidos.

Un efecto práctico: consultas que en otros motores pasan mucho tiempo en overhead de ejecución pueden bajar bastante su tiempo total. No porque DuckDB “adivine” mejor, sino porque hace menos trabajo inútil alrededor del trabajo útil.

Columnar por dentro, pero sin complicarte por fuera

DuckDB usa almacenamiento columnar internamente para muchas operaciones analíticas. Eso quiere decir que guarda y procesa los datos por columnas, no por filas. Para analítica, eso suele ser mejor porque lees solo las columnas que necesitas y comprimes mejor.

La ventaja se ve rápido en consultas como estas: si solo quieres country, revenue y created_at, no tiene sentido cargar veinte columnas más. Un motor columnar puede saltarse lo que no hace falta y mover menos datos desde disco o memoria.

Lo interesante es que DuckDB combina esa idea con una experiencia de uso muy simple. Tú no tienes que pensar en particiones, cubos o tuning complejo para empezar. Abres el motor, consultas archivos, y ya.

Compresión y menos bytes movidos

La velocidad no viene solo de la CPU. También viene de mover menos bytes. DuckDB usa técnicas de compresión y codificación que ayudan a reducir el volumen de datos que viaja desde almacenamiento a memoria y de memoria a CPU.

Eso importa mucho en datasets grandes. Si comprimes mejor una columna con muchos valores repetidos, por ejemplo estados, categorías o códigos de país, el motor puede leer menos y procesar más rápido. En analítica real, ese patrón es común.

Un detalle práctico: cuando comparas un motor columnar con uno orientado a filas, no siempre ganas en cada consulta. Pero en reportes, filtros por columnas y agregaciones, el ahorro suele ser claro. Ahí es donde DuckDB se siente muy bien.

Lo que hace distinto al optimizador

DuckDB también gana por cómo planifica las consultas. No se limita a ejecutar SQL de forma literal. Intenta reorganizar filtros, empujar operaciones hacia abajo y elegir planes que reduzcan el trabajo total.

Eso suena obvio, pero en la práctica hay diferencias grandes entre motores. Un buen optimizador puede evitar leer datos innecesarios, aplicar filtros antes de joins caros y escoger estrategias de hash join o aggregations más convenientes según el tamaño de los datos.

Según la documentación oficial de DuckDB, el motor está pensado para aprovechar procesamiento analítico local y ejecución eficiente sobre una sola máquina. Puedes revisar sus docs en https://duckdb.org/docs/ para ver detalles de arquitectura y funciones soportadas.

Pushdown y lectura inteligente

Uno de los puntos más útiles es el pushdown de filtros y proyecciones. Si la consulta solo necesita una parte de los datos, el motor intenta evitar cargar el resto. En archivos Parquet esto es especialmente útil, porque el formato ya trae metadatos que facilitan saltarse bloques.

Ejemplo simple:

SELECT country, SUM(revenue)
FROM read_parquet('sales.parquet')
WHERE created_at >= DATE '2025-01-01'
GROUP BY country;

En una consulta así, el motor no debería comportarse como si tuviera que leer todo y luego filtrar al final. Mientras más temprano descarte filas o columnas, menos trabajo hace después.

Join y agregaciones con menos fricción

En analítica, los joins y las agregaciones suelen ser los puntos caros. DuckDB intenta elegir estrategias que funcionen bien para datos en memoria o cercanos a memoria. En una sola máquina, eso puede ser suficiente para datasets bastante grandes.

Aquí vale una regla práctica: si tu consulta hace muchos joins entre tablas medianas y grandes, DuckDB puede rendir muy bien mientras el patrón sea analítico. Si el patrón es OLTP puro, con escrituras frecuentes y muchas transacciones pequeñas, Postgres sigue siendo el caballo de batalla.

DuckDB frente a Postgres: cuándo conviene cada uno

La comparación con Postgres aparece siempre, pero no porque uno sea objetivamente mejor que el otro. Son motores pensados para problemas distintos. Postgres es una base generalista excelente. DuckDB es una máquina analítica muy afinada para una sola computadora.

Si tú administras una app con usuarios concurrentes, permisos, escrituras constantes y necesidad de consistencia transaccional, Postgres suele ser la elección natural. Si lo que quieres es correr consultas pesadas sobre datos locales, archivos o tablas replicadas para análisis, DuckDB puede darte mejor experiencia.

La diferencia también se nota en la operación. Postgres requiere pensar en índices, VACUUM, conexiones, tuning y, muchas veces, escalado. DuckDB reduce bastante esa carga cuando el problema es analítico y el dato cabe o casi cabe en una sola máquina.

Comparación práctica

No se trata de reemplazar uno por otro. Se trata de elegir mejor. Si tu producto necesita análisis local rápido, DuckDB te quita mucha complejidad. Si tu producto necesita transacciones y concurrencia, Postgres sigue siendo la base principal.

Una regla simple para decidir

1. Si tu carga principal es lectura analítica, evalúa DuckDB primero.
2. Si necesitas muchas escrituras concurrentes, empieza con Postgres.
3. Si quieres un motor embebido dentro de una app o notebook, DuckDB suele ser más cómodo.
4. Si el dataset vive en archivos Parquet o CSV, DuckDB te ahorra pasos intermedios.
5. Si necesitas un backend multiusuario con permisos y transacciones frecuentes, Postgres sigue siendo la opción más segura.

Ideas arquitectónicas que sí vale copiar

Aunque no uses DuckDB directamente, hay ideas que conviene llevarte a tus propios sistemas. La primera es clara: optimiza para el patrón real de uso, no para una idea genérica de base de datos. DuckDB no intenta ser todo para todos.

La segunda es pensar en bloques y no en operaciones granulares innecesarias. Procesar por lotes, reducir overhead y mejorar locality de caché son decisiones que ayudan en muchos sistemas de datos, no solo en motores SQL.

La tercera es minimizar el movimiento de datos. Leer solo columnas necesarias, empujar filtros temprano y evitar transformaciones costosas antes de tiempo son principios que aplican en ETL, servicios analíticos y pipelines de datos.

Qué copiar si estás construyendo producto

Si estás armando una app de datos o una capa analítica, estas ideas son especialmente útiles:

• Diseña para consultas frecuentes, no para todo el universo de SQL.
• Acerca el procesamiento al dato, en lugar de mover todo a otro sistema por defecto.
• Usa formatos columnar como Parquet cuando el caso sea analítico.
• Reduce el número de pasos en la ruta crítica de lectura y agregación.
• Mide el costo de serializar, deserializar y copiar datos, no solo el tiempo de consulta.

En equipos de Latinoamérica esto se nota mucho porque el costo operativo importa. Menos infraestructura, menos piezas y menos mantenimiento suelen ser ventajas reales. DuckDB encaja bien en ese enfoque porque te deja hacer mucho con poco.

Lo que debes mirar antes de adoptarlo

DuckDB no es la respuesta universal. Si lo metes en un caso equivocado, vas a sentir sus límites rápido. El más obvio es la concurrencia: no está pensado para servir como base transaccional principal con muchísimos usuarios y escrituras simultáneas.

También importa la memoria. Aunque DuckDB está muy bien optimizado, una consulta analítica muy pesada puede exigir bastante RAM. Si tu dataset es enorme y tu máquina es pequeña, tendrás que pensar en particionar, filtrar mejor o mover parte del trabajo.

Otro punto es la integración. DuckDB funciona muy bien en scripts, notebooks, apps embebidas y procesos batch. Pero si tu arquitectura depende de un ecosistema completo de permisos, replicación y operaciones distribuidas, probablemente necesites complementarlo con otras piezas.

Señales de que sí te conviene

DuckDB suele ser una buena apuesta cuando ves estas señales:

• Tu equipo trabaja con datos locales o replicados para análisis.
• Quieres reducir dependencia de un warehouse para tareas pequeñas o medianas.
• Necesitas respuestas rápidas en una app o notebook sin montar mucha infraestructura.
• Tus consultas son mayormente lectura, agregación y exploración.
• El costo de operación pesa tanto como la latencia.

Si eso te suena familiar, vale la pena probarlo en serio. No como curiosidad, sino como parte del stack.

Tabla resumen

DuckDB ganó terreno porque resuelve un problema muy concreto con una arquitectura muy enfocada. No intenta ser todo a la vez. Eso, en analítica, suele ser una ventaja enorme.

Si estás evaluando tu stack de datos, piensa primero en el patrón de consulta y en el costo operativo. Ahí es donde DuckDB suele brillar de verdad, y también donde Postgres sigue siendo mejor opción cuando el problema es otro.