DuckDB 2.0 plaide pour une analytique au plus près des données

Le cloud s’emploie depuis des années à nous convaincre que toute analytique sérieuse doit être effectuée dans le centre de données de quelqu’un d’autre. DuckDB 2.0 avance une proposition plus intéressante: l’architecture la plus intelligente n’oppose peut-être pas le cloud au local, mais consiste à savoir quelles opérations ne devraient jamais quitter la machine.

Sorti le 21 octobre 2026, DuckDB 2.0.0 LTS, baptisé « Cinnamon Teal », est la version apportant le plus grand nombre de fonctionnalités du projet à ce jour. Elle comprend un protocole Quack abouti, des entrées-sorties asynchrones, un type VARIANT de premier ordre, un mode agent, des déclencheurs et un analyseur SQL extensible, le tout issu de près de 20 000 commits depuis DuckDB 1.5, selon le projet DuckDB. La branche LTS est prise en charge jusqu’en octobre 2027 au moins.

Cette liste de fonctionnalités compte moins que l’orientation qui la sous-tend. DuckDB a commencé comme une base de données analytique in-process: du SQL exécuté à l’intérieur d’une application, d’un ordinateur portable ou d’un appareil en périphérie, plutôt que par l’intermédiaire d’un service de base de données fonctionnant en permanence. La version 2.0 élargit ce modèle sans l’abandonner. À nos yeux, c’est là l’essentiel.

DuckDB 2.0 considère le cloud comme une ressource, pas comme une destination par défaut

L’ajout le plus révélateur est Quack. DuckDB peut désormais servir des bases de données sur le réseau, tandis qu’un autre client DuckDB peut s’y connecter et exécuter des requêtes à distance grâce à la nouvelle instruction CONNECT. Cela ressemble à une base de données client-serveur classique, mais une différence essentielle demeure: les deux parties restent des instances DuckDB complètes. Le client peut toujours effectuer des calculs localement.

Il s’agit d’une réponse plus nuancée à l’architecture cloud que la simple construction d’un service hébergé de plus grande taille. Un ordinateur portable peut inspecter ou transformer des données localement, une base distante peut gérer les informations centralisées, et la frontière entre les deux peut être choisie requête par requête. Le même mécanisme CONNECT fonctionne également avec PostgreSQL et MySQL, tandis qu’un optimiseur de pushdown distant envoie les requêtes compatibles à ces serveurs au lieu de rapatrier des tables entières sur le réseau.

Cette souplesse est précieuse, car le déplacement des données constitue souvent le coût caché de l’analytique. Tout envoyer vers un entrepôt accroît la dépendance à la connectivité, ajoute de la latence et peut exposer inutilement des données sensibles. Tout conserver en local peut toutefois compliquer la collaboration, la gouvernance et la montée en charge centralisée. L’orientation de DuckDB 2.0 suggère un compromis pragmatique: déplacer les calculs lorsque cela présente un avantage, et non parce que l’architecture suppose que c’est obligatoire.

La description du projet est exceptionnellement claire sur ce point: DuckDB peut fonctionner aussi bien sur des appareils en périphérie que sur des serveurs dotés de centaines de cœurs, et travailler avec des fichiers locaux ou du stockage objet. La page de présentation de DuckDB présente cette portabilité comme une propriété fondamentale, et non comme une réflexion après coup.

La meilleure fonctionnalité cloud est celle qui donne l’impression que les données distantes sont locales

Les entrées-sorties asynchrones paraissent peut-être moins séduisantes qu’un nouveau protocole ou qu’un mode d’interface en ligne de commande orienté IA, mais c’est probablement la fonctionnalité dont les bénéfices pratiques sont les plus évidents pour les charges de travail fortement dépendantes du cloud. DuckDB 2.0 sépare les lectures distantes du traitement des requêtes, ce qui permet de conserver plusieurs demandes en cours pendant que le processeur travaille sur les données déjà disponibles.

Cette conception vise les fichiers Parquet et CSV stockés dans des stockages objets comme S3. Un rapport de MotherDuck décrit des lectures deux à trois fois plus rapides sur S3 dans son scénario de test, sans modifier les requêtes; ces chiffres proviennent d’un seul ordinateur portable et d’une connexion internet domestique et doivent donc être considérés comme ceux d’une expérience indicative, plutôt que comme une référence universelle. L’analyse de MotherDuck illustre néanmoins un point plus général: l’exécution locale ne signifie pas qu’il faut ignorer le cloud. Elle peut consister à utiliser le cloud comme espace de stockage tout en évitant un détour analytique lourd.

C’est là que le modèle de DuckDB devient convaincant. Un entrepôt reste utile lorsque de nombreux utilisateurs ont besoin d’analyses partagées, gouvernées et continuellement mises à jour. Mais pour un développeur qui explore un jeu de données, une application qui génère un rapport ou un système en périphérie qui filtre des événements avant leur envoi, payer le coût d’un cluster distant pour chaque question paraît de plus en plus excessif. L’unité d’optimisation pertinente n’est pas toujours le centre de données. Parfois, c’est l’aller-retour.

VARIANT rend l’analytique embarquée plus à l’aise avec les données désordonnées

Les systèmes analytiques locaux ont traditionnellement été particulièrement séduisants lorsque les données étaient déjà bien structurées. Les applications réelles sont moins coopératives. Les journaux évoluent, la forme des charges utiles des événements change et les équipes doivent souvent interroger des enregistrements semi-structurés avant que quiconque n’ait conçu un schéma parfait.

Le type VARIANT de DuckDB 2.0 répond à cette difficulté en stockant des données typées et dépourvues de schéma tout en préservant l’exécution en colonnes. Le moteur peut détecter une structure courante et la « décomposer » afin que les champs récurrents soient compressés et exécutés davantage comme des colonnes ordinaires. C’est une amélioration importante par rapport au traitement de chaque document JSON comme du texte, notamment pour les journaux et les flux d’événements dont la structure est en partie stable et en partie imprévisible.

La réserve est tout aussi importante: il ne s’agit pas de magie. Les données contenant des types de valeurs incohérents ne bénéficieront pas des mêmes avantages que les champs présentant une structure constante. DuckDB rend l’analytique locale sur des données flexibles plus performante, mais n’élimine pas le besoin de modéliser les données. C’est une force, pas une faiblesse. Les bons outils doivent réduire le coût des données imparfaites sans prétendre que leur qualité n’a plus d’importance.

Le label LTS compte parce que les outils locaux doivent s’inscrire dans la durée

Les logiciels embarqués sont faciles à adopter et faciles à abandonner. Un développeur peut rapidement intégrer une bibliothèque à une application, mais les systèmes en production ont besoin d’une maintenance prévisible, de chemins de migration et d’une stabilité suffisante pour justifier de construire autour de ce composant.

Le statut LTS de DuckDB 2.0 compte donc au-delà de la date de fin de prise en charge. Le projet indique que la version 2.0 bénéficiera d’un support jusqu’en octobre 2027 au moins, tandis que la précédente branche LTS 1.4 restera prise en charge jusqu’à fin novembre 2026 et que DuckDB 1.5 a été prolongé jusqu’en mars 2027. Ce chevauchement laisse aux équipes le temps de tester, au lieu de transformer une mise à niveau majeure en urgence.

On peut aussi y voir un signal stratégique. DuckDB ajoute la connectivité aux serveurs, l’observabilité et un comportement de ligne de commande adapté aux agents sans renoncer à son identité de moteur in-process. Le résultat ne remplace pas un entrepôt cloud, et il ne faudrait pas le présenter ainsi. Il permet de rendre l’analytique plus composable: dans un ordinateur portable aujourd’hui, dans une application demain, puis connectée à une infrastructure centralisée lorsque la charge de travail l’exige réellement.

Notre verdict est simple: DuckDB 2.0 mérite d’être surveillé non parce qu’il rend l’analytique locale universellement supérieure, mais parce qu’il rend plus difficile de balayer d’un revers de main une architecture combinant traitement local et distant. Les équipes devraient conserver les entrepôts centralisés pour la montée en charge partagée et la gouvernance, tout en envisageant sérieusement DuckDB pour l’exploration, les rapports embarqués, le traitement en périphérie et les analyses portant sur des données sensibles. L’avenir du traitement des données ne reposera probablement pas sur des clusters toujours plus gros partout. Il consistera à mieux déterminer où chaque requête doit être exécutée.