DuckDB 2.0 peut désormais fonctionner comme serveur. Voici quand ça change votre stack — et quand ça ne le change pas.

DuckDB a sorti la version 2.0.0 le 21 octobre, la plus grande mise à jour de l'histoire du projet et le début d'une nouvelle ligne de support à long terme, baptisée « Cinnamon Teal ». Le point fort : DuckDB, une base de données en cours de processus depuis le premier jour, peut désormais fonctionner comme serveur. Une version simplifiée de son protocole Quack permet à un processus DuckDB de servir ses bases de données sur le réseau, et une nouvelle instruction CONNECT permet à une autre session de s'y connecter et d'y acheminer des requêtes. L'outil en ligne de commande a reçu les raccourcis -serve et -connect pour la même chose. CONNECT fonctionne aussi avec PostgreSQL et MySQL, où un nouvel optimiseur de pushdown envoie la requête au serveur distant plutôt que de rapatrier des tables entières.

Il y a bien d'autres nouveautés. L'I/O asynchrone accélère considérablement les lectures depuis S3 et d'autres stockages objets. Un type VARIANT de première classe gère les données semi-structurées. On trouve aussi des déclencheurs, un parseur SQL basé sur PEG auquel les extensions peuvent ajouter de la syntaxe, et un nouveau format de stockage par défaut. Tout cela provient de près de 20 000 commits depuis DuckDB 1.5.

Le mode serveur est optionnel. Traitez-le comme tel.

DuckDB séduisait avant tout par l'absence de serveur à gérer. On l'embarquait, on le pointait sur des fichiers Parquet ou CSV, et on obtenait des analyses en colonnes directement dans son propre processus. Le mode serveur 2.0 ne change pas ce comportement par défaut, et la plupart des équipes ne devraient pas s'y précipiter dès le premier jour. Le moteur embarqué reste l'outil adapté à la grande majorité des charges de travail analytiques. Le mode réseau est réservé au cas particulier où plusieurs clients ont véritablement besoin de partager une même instance active.

Dans notre travail de développement PHP et Docker sur des applications à forte intensité de données, nous avons vu des équipes déployer un réplica Postgres séparé, voire un entrepôt de données complet, pour alimenter un écran de reporting qui ne faisait en réalité que requêter quelques fichiers. DuckDB embarqué aurait fait ce travail sans infrastructure supplémentaire à gérer ou à patcher. La nouvelle I/O asynchrone est l'amélioration discrète ici. Elle rend la version de ce modèle sauvegardée sur S3 suffisamment rapide pour que les reportings de taille moyenne n'aient plus besoin de leur propre serveur de base de données. Si vous développez des applications cloud-native sur AWS, ça supprime une pièce mobile.

Le modèle en cours de processus s'adapte bien aussi. Dans nos projets natifs iOS et Android, notamment les applications offline-first dans la santé et l'IoT, les analyses sur l'appareil impliquent généralement d'écrire des requêtes à la main sur SQLite ou d'envoyer les données à un backend pour les traiter. Un moteur analytique qui fonctionne dans l'application, hors ligne, s'adapte mieux à ce travail que l'une ou l'autre option. C'est le genre de choix d'architecture que nous faisons souvent dans nos projets clients.

Là où je ralentirais : l'exposition de Quack

Le mode serveur est la partie qui m'inquiète. Par défaut, le serveur Quack n'écoute que sur localhost, ce qui est le bon choix. La documentation est claire : l'option allow_other_hostname, celle qui l'expose directement, est « uniquement destinée aux tests ». Si vous souhaitez un véritable accès distant, gardez le serveur sur localhost et placez un proxy inverse avec terminaison TLS devant lui. Lors de nos missions de pentest, c'est l'une des façons les plus courantes dont un service est compromis : il est livré avec un paramètre sûr par défaut, quelqu'un bascule un réglage pratique pour faire fonctionner une démo, et la chose se retrouve non authentifiée sur une IP publique. Traitez un port Quack comme n'importe quel autre port de base de données. Utilisez le token, terminez le TLS au niveau d'un proxy, et ne l'exposez jamais directement sur Internet.

Le piège de la mise à jour : le format de stockage

Le seul changement cassant qui va poser problème est le format de stockage. Par défaut, la version 2.0 écrit dans un nouveau format que les versions de DuckDB antérieures à 2.0 ne peuvent pas lire. L'inverse ne pose pas de problème. La version 2.0 lit et écrit vos fichiers existants, qui restent lisibles par les versions précédentes. Le problème vient des flottes mixtes. Dès qu'un processus 2.0 crée ou réécrit une base de données dans le nouveau format, chaque DuckDB plus ancien qui touche ce fichier échoue avec une erreur de version. Si vous exécutez de nombreux processus DuckDB à différentes versions, c'est un problème de coordination, pas une simple mise à jour.

Donc avant de mettre à jour quoi que ce soit, faites l'inventaire des emplacements où vos fichiers DuckDB sont lus, et par quelles versions. Si deux services partagent un fichier et qu'un seul passe à 2.0, la première écriture du côté mis à jour cassera l'autre en production. Épinglez les versions de DuckDB dans vos Dockerfiles et fichiers de verrouillage, mettez à jour les écrivains en dernier, et gardez un repli sur l'ancienne ligne pendant les tests. L'équipe DuckDB suggère d'essayer d'abord la version 2.0 sur un système fantôme et conseille aux charges de travail critiques d'attendre le premier patch, prévu en novembre. C'est un conseil avisé. Surveillez aussi l'horloge sur les lignes plus anciennes : le support de la 1.4 se termine le 17 novembre, et la 1.5 a été prolongée jusqu'en mars 2027 pour laisser le temps aux équipes de migrer.

Pourquoi l'étiquette LTS est importante

Une dernière chose à signaler pour les équipes qui ont des auditeurs dans la salle. La version 2.0 est une version LTS, supportée jusqu'en octobre 2027 au moins. Pour nos clients suisses en entreprise avec des exigences de conformité, « supporté jusqu'à une date précise » est souvent la différence entre une dépendance qui passe la revue et une qui ne le fait pas. C'est une vraie raison de préférer la ligne LTS plutôt que de suivre chaque version de fonctionnalités.

Si intégrer des analyses dans un produit sans déployer un entrepôt de données entier, ou sécuriser un nouveau service de données avant son lancement, vous parle, discutons-en.