El proyecto DuckDB publicó el 21 de octubre la versión 2.0.0, con nombre en clave «Cinnamon Teal», la primera del motor analítico embebido que llega con soporte a largo plazo. El equipo la presenta como su entrega de funcionalidad más grande hasta la fecha y mantendrá el soporte de esta rama hasta octubre de 2027, mientras la 1.5 queda cubierta hasta marzo de ese mismo año.
El cambio con más consecuencias arquitectónicas es el protocolo Quack, una implementación cliente-servidor con una nueva sentencia CONNECT para acceder a bases de datos remotas. DuckDB nació como motor embebido —una biblioteca dentro del proceso de la aplicación, sin servidor que administrar— y ese modelo sigue siendo el habitual, pero la opción de hablar con una instancia remota abre escenarios que antes exigían montar otra pieza delante. Junto a eso llega la entrada y salida asíncrona: la lectura de Parquet, CSV y del formato nativo pasa a hacerse en segundo plano, lo que acelera de forma notable las consultas contra almacenamiento de objetos, que es donde más se nota la latencia de cada petición individual.
La versión incorpora también el tipo VARIANT para datos sin esquema fijo, con compresión y optimizaciones propias; disparadores BEFORE y AFTER, que habilitan tablas de auditoría y el mantenimiento incremental de vistas materializadas; un nuevo analizador sintáctico PEG, extensible mediante gramáticas de extensión; y repositorios de extensiones propios, para que una organización pueda alojar y firmar su propia colección de confianza en lugar de depender solo del repositorio público. Hay además un «modo agente» en la línea de comandos que detecta cuándo quien consulta es un agente de código y reduce el volumen de salida —un 59 % menos en las pruebas con TPC-H que cita el proyecto—, un detalle pequeño que ahorra contexto cuando el motor se usa desde una herramienta asistida por IA.
Conviene leer con atención los cambios que rompen compatibilidad, porque esta versión tiene varios. El formato de almacenamiento no es compatible hacia atrás: una versión anterior de DuckDB no puede leer ficheros escritos por la 2.0, así que la actualización de un entorno con datos persistidos hay que planificarla, no improvisarla. Se exige compilador C++17 en lugar de C++11, la sintaxis antigua de funciones lambda queda desactivada en favor de la de estilo Python, y quedan marcadas para retirada las compilaciones amalgamadas y el soporte de macOS sobre x86_64, que desaparece en la 2.1.
Para un equipo de datos en España, la relevancia está menos en la lista de funciones que en lo que significa un ciclo de soporte largo. DuckDB se ha convertido en la pieza por defecto para transformar datos en local, probar lógica antes de llevarla a un almacén y sostener cargas analíticas de tamaño medio sin pagar un clúster. Hasta ahora, llevar eso a producción obligaba a convivir con un calendario de versiones rápido; una rama con soporte declarado hasta octubre de 2027 cambia esa conversación y permite fijar una versión en un entorno productivo con un horizonte conocido.
El momento razonable para actuar es ahora, pero en un entorno de pruebas: comprobar que las consultas y extensiones propias siguen funcionando con el nuevo analizador y con la sintaxis de lambdas actualizada, y verificar el impacto de la incompatibilidad del formato de almacenamiento antes de mover nada en producción.
Más en Dataprix: sección de plataformas de datos de Dataprix
Fuente: DuckDB (blog oficial)
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.