DuckDB 2.0 ya puede ejecutarse como servidor. Cuándo cambia su stack y cuándo no.

DuckDB publicó la versión 2.0.0 el 21 de octubre, el lanzamiento más importante en la historia del proyecto y el inicio de una nueva línea de soporte a largo plazo, con el nombre en clave «Cinnamon Teal». El titular: DuckDB, una base de datos en proceso desde el primer día, ahora puede ejecutarse como servidor. Una versión depurada de su protocolo Quack permite que un proceso DuckDB sirva sus bases de datos en red, y una nueva instrucción CONNECT permite que otra sesión se conecte y enrute consultas hacia él. La herramienta de línea de comandos incorporó los atajos -serve y -connect para lo mismo. CONNECT también funciona con PostgreSQL y MySQL, donde un nuevo optimizador de pushdown envía la consulta al servidor remoto en lugar de traer tablas enteras a través de la red.

Hay mucho más en la caja. La E/S asíncrona hace que las lecturas desde S3 y otros almacenamientos de objetos sean mucho más rápidas. Un tipo VARIANT de primera clase gestiona datos semiestructurados. Hay disparadores, un analizador SQL basado en PEG al que las extensiones pueden añadir sintaxis, y un nuevo formato de almacenamiento predeterminado. Todo esto proviene de cerca de 20.000 commits desde DuckDB 1.5.

El modo servidor es opcional. Trátelo como tal.

El gran atractivo de DuckDB era que no había ningún servidor que ejecutar. Se integraba, se apuntaba a algún Parquet o CSV y se obtenía análisis columnar dentro del propio proceso. El modo servidor de la versión 2.0 no cambia ese comportamiento predeterminado, y la mayoría de los equipos no debería adoptarlo desde el primer día. El motor integrado sigue siendo la herramienta adecuada para la gran mayoría de las cargas de trabajo analíticas. El modo red es para el caso concreto en que varios clientes realmente necesitan compartir una instancia activa.

En nuestro trabajo de desarrollo en PHP y Docker con aplicaciones con muchos datos, hemos visto cómo los equipos levantaban una réplica de Postgres aparte, o incluso un almacén de datos completo, para respaldar una pantalla de informes que en realidad solo consultaba un puñado de archivos. DuckDB integrado habría hecho ese trabajo sin infraestructura adicional que ejecutar ni que parchear. La nueva E/S asíncrona es la mejora silenciosa aquí. Hace que la versión respaldada por S3 de ese patrón sea lo suficientemente rápida como para que los informes de tamaño mediano ya no necesiten su propio servidor de base de datos. Si desarrolla aplicaciones nativas en la nube en AWS, eso elimina una pieza móvil.

El modelo en proceso también funciona bien en movilidad. En nuestros proyectos nativos para iOS y Android, especialmente en aplicaciones offline-first en salud e IoT, el análisis en el dispositivo suele implicar escribir consultas manualmente sobre SQLite o enviar datos a un backend para procesarlos. Un motor analítico que se ejecuta dentro de la aplicación, sin conexión, encaja mejor en ese trabajo que cualquiera de las dos opciones. Es el tipo de decisión de arquitectura que tomamos con frecuencia en nuestro trabajo con clientes.

Dónde iría con más cuidado: exponer Quack

El modo servidor es la parte que me preocupa. Por defecto, el servidor Quack escucha únicamente en localhost, lo cual es la decisión correcta. La documentación es clara al señalar que la opción allow_other_hostname, la que lo expone directamente, está «pensada únicamente para pruebas». Si desea acceso remoto real, mantenga el servidor en localhost y coloque un proxy inverso con terminación TLS delante. Durante nuestros trabajos de pentesting, esta es una de las formas más comunes en que un servicio queda comprometido: viene con un valor predeterminado seguro, alguien cambia un ajuste cómodo para que funcione en una demo, y el servicio termina sin autenticación en una IP pública. Trate un puerto Quack como cualquier otro puerto de base de datos. Use el token, termine el TLS en un proxy y nunca lo exponga directamente a Internet.

La trampa de la actualización es el formato de almacenamiento

El único cambio de ruptura que va a afectar a la gente es el formato de almacenamiento. Por defecto, la versión 2.0 escribe un nuevo formato que las versiones de DuckDB anteriores a 2.0 no pueden leer. La dirección contraria está bien. La versión 2.0 lee y escribe sus archivos existentes, y estos siguen siendo legibles por versiones anteriores. El problema está en las flotas mixtas. En el momento en que un proceso 2.0 crea o reescribe una base de datos en el nuevo formato, todos los DuckDB más antiguos que toquen ese archivo fallan con un error de versión. Si ejecuta muchos procesos de DuckDB en diferentes versiones, eso es un problema de coordinación, no un simple cambio de línea.

Así que, antes de actualizar cualquier cosa, audite de dónde se leen sus archivos DuckDB y qué versiones los utilizan. Si dos servicios comparten un archivo y solo uno migra a 2.0, la primera escritura del lado actualizado rompe el otro en producción. Fije las versiones de DuckDB en sus Dockerfiles y archivos de bloqueo, actualice los escritores en último lugar y mantenga un fallback en la línea antigua mientras realiza las pruebas. El equipo de DuckDB sugiere probar la versión 2.0 primero en un sistema espejo y señala que las cargas de trabajo críticas deberían esperar al primer parche, previsto para noviembre. Es un consejo sensato. Esté también pendiente del reloj en las líneas más antiguas: el soporte de la versión 1.4 termina el 17 de noviembre, y la versión 1.5 se amplió hasta marzo de 2027 para dar margen de maniobra.

Por qué importa la etiqueta LTS

Una cosa más que vale la pena señalar para los equipos con auditores presentes. La versión 2.0 es una versión LTS, con soporte hasta al menos octubre de 2027. Para nuestros clientes empresariales suizos con requisitos de cumplimiento normativo, «con soporte hasta una fecha concreta» suele ser la diferencia entre una dependencia que supera la revisión y una que no. Esa es una razón real para preferir la línea LTS en lugar de perseguir cada versión de funcionalidades.

Si le resulta familiar integrar analíticas en un producto sin levantar un almacén de datos completo, o asegurar un nuevo servicio de datos antes de que salga a producción, hablemos.