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. Empezó como la base de datos analítica embebida pensada para analistas con portátil. A octubre de 2025 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. Impórtala como biblioteca, abre una base en disco o en memoria y ejecuta SQL estándar con su catálogo de 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 alta concurrencia de escritura. 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 la arquitectura: 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 se repite 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. Los patrones de consulta eran puntuales, unas cientos de consultas al día, y los costes mensuales 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 una vista ejecutiva, 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 más de un proceso intenta escribir al mismo archivo DuckDB a la vez, 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. Los pipelines se pueden ejecutar localmente sin conexión al warehouse de producción, y la configuración mínima ni siquiera escribe a disco: corre en memoria. Esa capacidad cubre desarrollo y testing, y deja 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 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 más de un proceso escribiendo a la vez. Para ingesta continua desde más de un productor, 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 en consulta activa.

  • 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. Sí 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 tiene dos umbrales: menos de 500 gigabytes de datos activos y menos de 10 consultas por segundo. Por debajo de ahí, 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 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. DuckDB: Why DuckDB, arquitectura embebida y motor columnar[1]
  2. dbt Labs: DuckDB setup, adapter dbt-duckdb[2]
  3. Apache Arrow: DuckDB quacks Arrow, a zero-copy data integration[3]

Preguntas frecuentes

¿Hasta qué volumen de datos puedo sustituir Snowflake o BigQuery por DuckDB?

Si tu carga tiene menos de 500 GB de datos activos y menos de 10 consultas por segundo, DuckDB merece una evaluación seria antes de asumir que necesitas un warehouse distribuido. El patrón consiste en escribir Parquet particionado en un bucket de almacenamiento de objetos y consultarlo con DuckDB desde un servidor o una función. En un proyecto concreto la factura mensual bajó de dos mil dólares a menos de cien. Con terabytes o decenas de usuarios concurrentes, los warehouses vuelven a tener sentido.

¿Puede DuckDB procesar un fichero más grande que la RAM de mi portátil?

Sí. DuckDB vuelca temporalmente a disco cuando la memoria no basta, con un algoritmo de ejecución que respeta los límites configurados. Un JOIN entre dos archivos de 50 GB cada uno se ejecuta, quizás lentamente, en un portátil con 16 GB de RAM. Desde la CLI puede procesar CSV, JSON o Parquet de cientos de gigabytes sin infraestructura, lo que encaja en reconciliaciones de datos puntuales y auditorías.

¿Qué no puede hacer DuckDB frente a un warehouse empresarial?

Tres cosas. No está pensado para concurrencia de escritura: si más de un proceso escribe al mismo archivo aparecen bloqueos, así que hay que separar escritura de lectura o usar piezas como ClickHouse para ingesta continua. No escala horizontalmente: corre en un solo proceso y una sola máquina, con frontera práctica en torno a uno o dos terabytes en consulta activa. Y no trae capa nativa de permisos, auditoría ni control de acceso, que hay que construir alrededor.

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