DuckDB 2.0 defiende mantener la analítica cerca de los datos

La nube lleva años convenciéndonos de que la analítica avanzada debe ejecutarse en el centro de datos de otra persona. DuckDB 2.0 llega con una propuesta más interesante: quizá la arquitectura más inteligente no consista en elegir entre la nube y lo local, sino en saber qué tareas no deberían salir nunca del equipo.

Publicado el 21 de octubre de 2026, DuckDB 2.0.0 LTS, cuyo nombre en clave es «Cinnamon Teal», es la mayor actualización de funcionalidades del proyecto hasta la fecha. Incluye un protocolo Quack más pulido, E/S asíncrona, un tipo VARIANT plenamente integrado, un modo para agentes, triggers y un analizador sintáctico SQL extensible, desarrollados a partir de casi 20.000 commits desde DuckDB 1.5, según el proyecto DuckDB. La rama LTS tendrá soporte hasta, como mínimo, octubre de 2027.

La lista de funciones importa menos que la dirección que marca. DuckDB nació como una base de datos analítica en proceso: SQL ejecutado dentro de una aplicación, un portátil o un dispositivo periférico, en lugar de depender de un servicio de base de datos en ejecución permanente. La versión 2.0 amplía ese modelo sin renunciar a él. En nuestra opinión, esa es la verdadera noticia.

DuckDB 2.0 trata la nube como un recurso, no como destino predeterminado

La incorporación más reveladora es Quack. DuckDB ahora puede servir bases de datos a través de la red, mientras que otro cliente DuckDB puede conectarse a ellas y dirigir consultas de forma remota mediante la nueva sentencia CONNECT. Suena a una base de datos cliente-servidor convencional, pero la diferencia importante es que ambos extremos siguen siendo instancias completas de DuckDB. El cliente aún puede realizar cálculos localmente.

Es una respuesta más matizada a la arquitectura cloud que limitarse a construir un servicio alojado más grande. Un portátil puede inspeccionar o transformar datos localmente, una base de datos remota puede encargarse de la información centralizada y el límite entre ambas puede elegirse consulta a consulta. El mismo mecanismo CONNECT también funciona con PostgreSQL y MySQL, mientras que un optimizador de pushdown remoto envía las consultas compatibles a esos servidores en lugar de descargar tablas enteras a través de la red.

Esa flexibilidad resulta valiosa porque el movimiento de datos suele ser el coste oculto de la analítica. Enviar todo a un almacén de datos aumenta la dependencia de la conectividad, añade latencia y puede exponer innecesariamente datos sensibles. Mantenerlo todo en local, sin embargo, puede dificultar la colaboración, la gobernanza y el escalado centralizado. La dirección de DuckDB 2.0 apunta a un compromiso práctico: mover el cálculo cuando resulte útil, no porque la arquitectura dé por hecho que debe hacerse.

La propia descripción del proyecto es especialmente clara en este punto: DuckDB puede ejecutarse en cualquier lugar, desde dispositivos periféricos hasta servidores con cientos de núcleos, y trabajar con archivos locales o almacenamiento de objetos. La página de la plataforma DuckDB presenta esa portabilidad como una propiedad esencial, no como algo añadido a posteriori.

La mejor función cloud es la que hace que los datos remotos parezcan locales

La E/S asíncrona puede sonar menos llamativa que un protocolo nuevo o que un modo de línea de comandos orientado a agentes, pero probablemente sea la función con un beneficio práctico más claro para las cargas de trabajo que dependen mucho de la nube. DuckDB 2.0 separa las lecturas remotas del procesamiento de consultas, lo que permite mantener varias solicitudes activas mientras la CPU trabaja con los datos que ya están disponibles.

Este diseño está pensado para archivos Parquet y CSV en almacenamiento de objetos como S3. Un informe de MotherDuck describe lecturas entre dos y tres veces más rápidas sobre S3 en su escenario de pruebas, sin cambiar las consultas; esas cifras se obtuvieron con un portátil y una conexión doméstica a internet, así que deben considerarse un experimento orientativo, no una referencia universal. El análisis de MotherDuck sigue ilustrando el punto general: la ejecución local no implica ignorar la nube. Puede significar usar la nube como almacenamiento y evitar, al mismo tiempo, un rodeo analítico pesado.

Aquí es donde el modelo de DuckDB resulta convincente. Un almacén de datos sigue siendo útil cuando muchos usuarios necesitan análisis compartidos, gobernados y actualizados de forma continua. Pero para un desarrollador que explora un conjunto de datos, una aplicación que genera un informe o un sistema periférico que filtra eventos antes de subirlos, pagar el coste de un clúster remoto por cada consulta parece cada vez más excesivo. La unidad de optimización adecuada no siempre es el centro de datos. A veces es el viaje de ida y vuelta.

VARIANT permite que la analítica integrada gestione mejor los datos desordenados

Los sistemas analíticos locales han resultado tradicionalmente más atractivos cuando los datos ya están ordenados. Las aplicaciones reales son menos cooperativas. Los registros evolucionan, los datos de eventos cambian de estructura y los equipos a menudo necesitan consultar registros semiestructurados antes de que nadie haya diseñado un esquema perfecto.

El tipo VARIANT de DuckDB 2.0 aborda esa fricción almacenando datos tipados y sin esquema, al tiempo que conserva la ejecución columnar. El motor puede detectar estructuras comunes y «descomponerlas» para que los campos recurrentes se compriman y se ejecuten de forma más parecida a las columnas normales. Es una mejora importante frente a tratar cada documento JSON como texto, especialmente en registros y flujos de eventos cuya estructura es en parte estable y en parte impredecible.

La advertencia es igual de importante: no es magia. Los datos con tipos de valores incoherentes no ofrecerán los mismos beneficios que los campos con una estructura coherente. DuckDB hace que la analítica local flexible sea más capaz, pero no elimina la necesidad de modelar los datos. Eso es una fortaleza, no una debilidad. Las buenas herramientas deben reducir el coste de trabajar con datos imperfectos sin fingir que la calidad de los datos ha dejado de importar.

La etiqueta LTS importa porque las herramientas locales necesitan continuidad

El software embebido es fácil de adoptar y fácil de abandonar. Un desarrollador puede incorporar rápidamente una biblioteca a una aplicación, pero los sistemas de producción necesitan un mantenimiento predecible, vías de migración y estabilidad suficiente para justificar que se construya sobre ese componente.

Por eso, el estado LTS de DuckDB 2.0 importa más allá de la fecha de soporte. El proyecto afirma que la versión 2.0 tendrá soporte hasta, como mínimo, octubre de 2027, mientras que la anterior rama 1.4 LTS seguirá recibiéndolo hasta finales de noviembre de 2026 y DuckDB 1.5 ha ampliado su soporte hasta marzo de 2027. Esta superposición da margen a los equipos para probar, en lugar de convertir una actualización importante en una emergencia.

También hay una señal estratégica. DuckDB está incorporando conectividad con servidores, observabilidad y un comportamiento de línea de comandos más adecuado para agentes sin renunciar a su identidad como motor en proceso. El resultado no es un sustituto de un almacén de datos cloud, ni debería venderse como tal. Es una forma de hacer que la analítica sea más componible: hoy dentro de un portátil, mañana dentro de una aplicación y conectada a la infraestructura centralizada cuando la carga de trabajo lo exija realmente.

Nuestro veredicto es sencillo: merece la pena seguir de cerca DuckDB 2.0 no porque convierta la analítica local en una opción universalmente superior, sino porque hace más difícil descartar una arquitectura distribuida entre lo local y lo remoto. Los equipos deberían mantener los almacenes de datos centralizados para el escalado compartido y la gobernanza, y considerar seriamente DuckDB para la exploración, los informes integrados, el procesamiento en el extremo y los análisis sensibles desde el punto de vista de la privacidad. Probablemente, el futuro del procesamiento de datos no consista en instalar clústeres más grandes en todas partes, sino en decidir mejor dónde debe ejecutarse cada consulta.