Actualizado: 2026-07-07

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. Según describe la propia documentación del proyecto[1], no hay «software de servidor que instalar, actualizar y mantener»: no requiere despliegue, no consume recursos cuando no se la está consultando. Basta importarla como biblioteca, 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, y ya la comparamos con más detalle en SQLite y DuckDB: cuándo cada una es la opción correcta. SQLite es por filas y está optimizado para transacciones pequeñas con muchas escrituras concurrentes. DuckDB es columnar y está 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: el motor vectorizado de DuckDB procesa la columna en bloques, y ese modelo de almacenamiento está pensado justo para lo que hace la 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 el adapter dbt-duckdb, documentado en el propio sitio de dbt[2], 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: la configuración mínima ni siquiera escribe a disco, corre en memoria. 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, algo que ya tratamos con más detalle en Polars frente a pandas en 2025: la práctica real. Puedes pasar un DataFrame de pandas como tabla a una consulta DuckDB y recibir el resultado como DataFrame sin copiarlo. 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, tal y como documenta el propio proyecto Apache Arrow[3].

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. En sectores donde el cumplimiento regulatorio pesa mucho, estas capacidades hay que construirlas alrededor.

Mi lectura

DuckDB ha terminado de ganarse su hueco en el terreno de la analítica de empresa. 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. La prueba de concepto suele tardar días, y el resultado, casi siempre, 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.

Este artículo también está disponible en inglés: DuckDB in enterprise analytics: concrete cases.

Fuentes

  1. la propia documentación del proyecto
  2. el adapter dbt-duckdb, documentado en el propio sitio de dbt
  3. documenta el propio proyecto Apache Arrow