DuckDB en analítica de empresa: casos concretos
Actualizado: 2026-05-03
DuckDB es uno de esos proyectos que llevan dos o tres años creciendo sin hacer ruido y que de repente aparecen en todas partes. Lo que empezó como la base de datos analítica embebida pensada para analistas con portátil se ha convertido, a octubre de 2025, en una pieza que aparece en arquitecturas de empresa de tamaño pequeño y medio con una frecuencia sorprendente. Este artículo recoge los patrones concretos donde se usa, dónde desplaza a piezas más caras y dónde todavía no llega.
Puntos clave
- DuckDB es un motor OLAP columnar embebido que lee Parquet de disco local o de S3 sin importarlo, tratándolo como tablas virtuales.
- El patrón más frecuente en empresa es reemplazar un warehouse cloud pequeño (100-500 GB, pocas centenas de consultas al día) con DuckDB más Parquet en almacenamiento de objetos.
- Las consultas de agregación que SQLite tarda veinte segundos las resuelve DuckDB en medio segundo; la diferencia es el modelo de almacenamiento columnar.
- Los límites son claros: sin concurrencia de escritura, sin escala horizontal y sin capa de gobernanza nativa.
- Si tu carga tiene menos de 500 GB de datos activos y menos de 10 consultas por segundo, DuckDB merece evaluación seria antes de asumir que necesitas un warehouse distribuido.
Qué lo hace distinto
DuckDB es una base de datos OLAP columnar que corre embebida en el proceso que la usa. No tiene servidor, no requiere despliegue, no consume recursos cuando no se la está consultando. Basta importarla como librería, abrir una base en disco o en memoria y ejecutar SQL estándar con muchas extensiones analíticas.
La diferencia clave con SQLite es el motor de almacenamiento. SQLite es por filas y optimizado para transacciones pequeñas con muchas escrituras concurrentes. DuckDB es columnar y optimizado para escaneos analíticos sobre millones de filas. Una consulta de agregación que en SQLite toma veinte segundos, en DuckDB puede tardar medio. No es magia, es que el modelo de almacenamiento está pensado para lo que hace analítica.
La segunda diferencia importante es el soporte nativo de Parquet. DuckDB puede leer archivos Parquet de disco local o de S3 sin tener que importarlos antes, tratándolos como tablas virtuales. Esto cambia la ecuación de muchas arquitecturas: Parquet como formato de almacenamiento primario, DuckDB como motor de consulta, sin un warehouse de por medio.
Reemplazo de warehouses pequeños
El primer patrón que aparece con frecuencia es reemplazar un warehouse cloud pequeño por DuckDB más Parquet en almacenamiento de objetos. En los casos acompañados, eran arquitecturas donde Snowflake o BigQuery se usaban con volúmenes de datos pequeños (entre 100 y 500 gigabytes), con patrones de consulta puntuales (unas cientos de consultas al día) y con costes mensuales que no se correspondían con el uso real.
El reemplazo típico consiste en:
- Escribir los datos como Parquet particionado en un bucket de almacenamiento de objetos.
- Usar DuckDB en un servidor o en una función para ejecutar las consultas.
El coste de almacenamiento baja a centavos por gigabyte al mes, y el coste de cómputo se limita a los minutos reales de consulta. En un proyecto concreto, la factura mensual bajó de dos mil dólares a menos de cien, sin perder capacidad real porque las consultas ejecutadas encajaban perfectamente en DuckDB.
El límite obvio de este patrón es el volumen. DuckDB puede con decenas o cientos de gigabytes cómodamente, especialmente si los datos están bien particionados y las consultas filtran por partición. Cuando los datos pasan a terabytes o hay decenas de usuarios concurrentes ejecutando consultas pesadas, los warehouses tradicionales vuelven a tener sentido.
Motor de analítica detrás de APIs
El segundo patrón es usar DuckDB como motor de consulta detrás de APIs de datos. El patrón dominante para este caso ha sido una base de datos transaccional replicada a una OLAP para analítica, con todo el coste operativo de mantener la replicación. DuckDB permite una alternativa: generar extractos periódicos en Parquet, consultarlos directamente con DuckDB desde el servicio de API y servir respuestas de analítica con latencia de milisegundos.
El patrón encaja especialmente bien para APIs internas o paneles de control empresariales donde los datos no tienen que estar al minuto. Una actualización cada quince minutos o cada hora es suficiente para la mayoría de vistas ejecutivas, y simplifica mucho la arquitectura. Equipos que venían de Redshift o ClickHouse dedicados a este caso han bajado la complejidad operativa a cero manteniendo tiempos de respuesta equivalentes o mejores.
Un detalle importante: DuckDB no está pensada para alta concurrencia de escritura. Si varios procesos intentan escribir al mismo archivo DuckDB simultáneamente, aparecen bloqueos. La arquitectura que funciona es separar escritura de lectura.
Procesamiento de archivos grandes sin infraestructura
El tercer patrón es el más sorprendente por lo simple. DuckDB puede procesar archivos CSV, JSON o Parquet de cientos de gigabytes desde la línea de comandos sin infraestructura ninguna. Un analista con portátil y DuckDB CLI puede ejecutar consultas sobre archivos que antes requerían un cluster Spark o un trabajo ETL en el warehouse.
El mecanismo interno es que DuckDB usa volcado temporal a disco cuando la memoria no basta, con un algoritmo de ejecución que respeta los límites configurados. Una consulta con JOIN entre dos archivos de 50 gigabytes cada uno se ejecuta, quizás lentamente, pero se ejecuta, en un portátil con 16 gigabytes de RAM.
Donde más sorprende este patrón es en laboratorios de análisis, en tareas puntuales de reconciliación de datos y en auditorías. Un equipo que necesite cruzar un fichero bancario con un extracto de ERP puede hacerlo con un comando DuckDB y recibir resultados en minutos, sin tener que importar nada a una herramienta dedicada.
Cómo encaja con dbt y con Python
DuckDB se ha integrado bien con dos ecosistemas que importan especialmente en empresa: dbt y Python.
Para dbt existe un adapter oficial que permite tratar DuckDB como cualquier otro motor, con el beneficio de que los pipelines se pueden ejecutar localmente sin conexión al warehouse de producción. Muchos equipos usan esta capacidad para desarrollo y testing, manteniendo Snowflake o BigQuery solo para producción. Esto conecta directamente con la pila que analizamos en data engineering moderno con Iceberg y dbt.
Para Python, DuckDB integra con pandas, Polars y Arrow de forma muy fluida. Puedes pasar un DataFrame de pandas como tabla a una consulta DuckDB y recibir el resultado como DataFrame. La combinación Polars más DuckDB es particularmente interesante: ambos son motores analíticos de alto rendimiento, y el paso de uno a otro mediante el formato Arrow es cero-copia.
Límites reales
No todo es positivo. Hay tres áreas donde DuckDB sigue flojo en 2025:
- Concurrencia de escritura: no está pensado para muchos procesos escribiendo simultáneamente. Para ingesta continua desde varios productores, hacen falta patrones de diseño adicionales o piezas alternativas como ClickHouse.
- Escala horizontal: corre en un solo proceso, en una sola máquina. La frontera práctica está en torno a uno o dos terabytes de datos que necesita consultarse frecuentemente.
- Gobernanza: no tiene nativamente la capa de permisos, auditoría o control de acceso que un warehouse empresarial trae. Para casos donde el cumplimiento regulatorio es crucial, estas capacidades hay que construirlas alrededor.
Mi lectura
DuckDB ha terminado de ganarse su hueco en el panorama de analítica. No reemplaza a Snowflake ni a BigQuery en casos donde la escala lo justifica, pero reemplaza a warehouses infrautilizados, a bases de datos OLTP mal usadas para analítica, a clusters Spark sobredimensionados para cargas pequeñas y a instalaciones de ClickHouse montadas para volúmenes que no lo necesitan. Para todos esos casos, DuckDB baja el coste, baja la complejidad operativa y sube la velocidad.
La recomendación concreta es que si tu carga de analítica tiene menos de 500 gigabytes de datos activos y menos de 10 consultas por segundo, DuckDB merece una evaluación seria antes de asumir que necesitas un warehouse distribuido. En muchos casos la prueba de concepto tarda días y el resultado es un orden de magnitud mejor en coste.
Conclusión
DuckDB hace una cosa muy bien, y eso también significa que hay cosas que no hace. Reconocer dónde encaja y dónde no es parte de la ingeniería, no defecto del proyecto.
