DuckDB 2.0 : un mode serveur, un mode agent et des ruptures à préparer

DuckDB est une base de données analytique qui tient dans un seul programme : pas de serveur à installer, on interroge directement des fichiers CSV, Parquet ou une base locale. Elle sert surtout à explorer et agréger des données. Sa version 2.0.0, nom de code « Cinnamon Teal », est sortie le 21 octobre 2026. L'équipe la présente comme sa plus grosse version, avec près de 20 000 modifications du code depuis la 1.5.

Ce qui arrive

• Un mode serveur. L'extension quack permet à n'importe quel processus DuckDB de servir ses bases à d'autres. Côté serveur : CALL quack_serve(token = 'my_token');. Côté client, la nouvelle instruction CONNECT attache la base distante et s'y place en une étape. Elle fonctionne aussi vers PostgreSQL et MySQL, et un optimiseur envoie les requêtes au serveur distant au lieu de rapatrier les tables.
• Un mode agent. Quand la ligne de commande est pilotée par un agent de code, DuckDB affiche des tableaux Markdown compacts, signale les résultats tronqués, arrête tôt les requêtes qui s'emballent, renvoie les erreurs en JSON et indique le coût attendu d'une requête avant de la lancer. L'équipe annonce, sur ses essais avec le jeu de test TPC-H, 59 % de texte en moins à lire pour le modèle. Les options -agent et -no-agent forcent ou coupent ce mode.
• Des jointures NEAREST, pour retrouver les éléments les plus proches d'un autre, pensées pour la recherche par similarité sur des vecteurs.
• Un type VARIANT pour les données semi-structurées comme le JSON, stockées en colonnes.
• Des déclencheurs (CREATE TRIGGER), avec quelques combinaisons non prises en charge.

Les ruptures à connaître

Le guide de migration en liste une douzaine. Les plus susceptibles de casser un script existant :

• Format de fichier. Une base créée par la 2.0 ne peut pas être ouverte par une version antérieure. Les fichiers existants restent lisibles des deux côtés tant qu'ils gardent leur version de stockage d'origine.
• Fonctions lambda. L'écriture à flèche simple (x -> x + 1) est désactivée par défaut. Il faut écrire lambda x: x + 1. Un réglage la rétablit provisoirement, mais il disparaîtra en 2.1.
• Nouvel analyseur SQL. Il remplace celui hérité de PostgreSQL. L'ancien reste accessible avec SET enable_legacy_parser = true;.
• Transactions. Toute erreur dans une transaction explicite l'invalide jusqu'à son annulation.
• Division par zéro. Les opérateurs // et % lèvent maintenant une erreur.
• Python. Le client exige Python 3.11 ou plus récent.

Le calendrier de support

• 2.0 : version à support long, maintenue au moins jusqu'en octobre 2027.
• 1.5 : support prolongé jusqu'en mars 2027.
• 1.4 : fin de support le 17 novembre 2026.

Un premier correctif de la 2.0 est annoncé pour novembre.

Les limites

Le mode serveur n'écoute par défaut que sur la machine locale. Pour un accès distant, la documentation renvoie vers un serveur mandataire qui assure le chiffrement TLS : ce n'est pas un serveur de base de données prêt à être exposé sur Internet. La nouvelle interface C pour les extensions n'est pas encore déclarée stable, et les dépôts d'extensions privés sont présentés comme un chantier en cours. Le chiffre de 59 % vient de l'éditeur, sur un jeu de test standard, pas sur vos données.

Notre lecture

Les utilisateurs encore en 1.4 doivent bouger avant le 17 novembre. La 1.5, maintenue jusqu'en mars 2027, est une étape sans risque. Pour la 2.0, l'équipe conseille elle-même d'essayer d'abord sur une copie de l'existant, et suggère aux usages critiques d'attendre le correctif de novembre. Nous suivrions ce conseil. Si plusieurs outils lisent le même fichier de base, mettez-les tous à jour ensemble. Pour ceux qui laissent un assistant de code interroger leurs exports comptables ou commerciaux, le mode agent est la nouveauté la plus directement utile : moins de texte envoyé au modèle, donc moins de jetons facturés.