DuckDB 2.0 ajoute le mode serveur, les E/S asynchrones et la prise en charge du type variant

L'équipe DuckDB a publié la version 2.0.0 LTS, nommée « Cinnamon Teal », marquant un changement significatif d'une pure stabilité vers une expansion majeure des fonctionnalités. Cette mise à jour, publiée le 21 octobre 2026, introduit des capacités de serveur natives, des opérations d'entrée/sortie asynchrones et une gestion améliorée des données semi-structurées. Elle représente la plus grande sortie de fonctionnalités dans l'histoire du projet, construite sur près de 20 000 commits depuis la version 1.5.

Ce qui s'est passé

DuckDB a traditionnellement fonctionné comme une base de données in-process, ce qui signifie qu'elle s'exécute dans le même espace mémoire que l'application qui l'utilise. La version 2.0 modifie cette architecture en peaufinant le protocole Quack, qui permet à DuckDB de fonctionner dans une configuration classique client-serveur. La nouvelle instruction CONNECT permet aux utilisateurs de joindre et de basculer vers des bases de données distantes en une seule commande, améliorant l'ergonomie pour les flux de travail distribués. Bien que le serveur écoute par défaut uniquement sur localhost pour des raisons de sécurité, il peut être placé derrière un proxy inverse terminant TLS pour accepter des connexions externes en toute sécurité.

Les améliorations de performance sont au cœur de cette sortie, notamment grâce à l'introduction des E/S asynchrones. Cette fonctionnalité permet à la couche d'E/S de monter en échelle indépendamment du traitement des requêtes, en émettant des lectures en arrière-plan et en maintenant plusieurs requêtes en vol. Ce changement booste considérablement le parallélisme pour les lectures à distance, entraînant des requêtes nettement plus rapides lors de l'accès à des services de stockage d'objets comme Amazon S3. De plus, le type VARIANT, introduit dans la version 1.5, est désormais entièrement intégré en tant que citoyen de première classe. Il stocke des données sans schéma telles que JSON tout en maintenant les performances d'exécution colonnaire, détectant automatiquement les structures communes pour optimiser la compression et la vitesse.

La sortie inclut également des mises à jour substantielles de l'extensibilité et des fonctionnalités SQL. Un nouveau analyseur basé sur PEG remplace l'ancien analyseur dérivé de PostgreSQL, permettant aux extensions de s'accrocher directement à la grammaire et fournissant des messages d'erreur plus précis. Les déclencheurs (triggers) sont désormais pris en charge, permettant des actions automatiques comme la journalisation d'audit ou le maintien incrémental de vues matérialisées. En outre, les utilisateurs peuvent désormais héberger leurs propres dépôts d'extensions fiables, permettant aux organisations de signer et de distribuer des extensions personnalisées en toute sécurité au sein de leur infrastructure.

Détails clés

• Support à long terme : DuckDB 2.0 est une sortie LTS supportée jusqu'à au moins octobre 2027, tandis que le support de la version 1.5 a été étendu jusqu'en mars 2027 pour faciliter la migration.
• Mode Agent : L'interface CLI détecte les agents de codage comme Claude Code ou Cursor et passe en mode de sortie compact, réduisant l'utilisation de tokens de 59 % lors des tests.
• E/S Asynchrones : La lecture asynchrone pour les formats Parquet, CSV et natifs améliore le débit des sources de données distantes en découplant les E/S de l'exécution des requêtes.
• Type VARIANT : Une prise en charge entièrement intégrée des données semi-structurées permet un stockage et une interrogation efficaces de structures similaires à JSON sans la surcharge liée au format texte.
• Dépôts personnalisés : Les organisations peuvent enregistrer et héberger leurs propres dépôts d'extensions avec des packages signés RSA pour une distribution interne sécurisée.
• Changements cassants : Les fichiers de base de données créés par la version 2.0 ne peuvent pas être lus par les versions antérieures, bien que la version 2.0 puisse toujours lire les fichiers des versions précédentes.

Contexte

Pour les équipes peu familières avec ce changement, passer d'une base de données in-process à un modèle client-serveur implique de séparer le moteur de base de données de la logique applicative. Dans une configuration in-process, la bibliothèque de base de données s'exécute directement dans la mémoire de l'application, ce qui simplifie le déploiement mais limite l'accès concurrent. Le nouveau protocole Quack permet à DuckDB d'écouter les connexions sur un réseau, autorisant plusieurs clients à interroger les mêmes données simultanément. Cela reflète l'architecture de systèmes traditionnels comme PostgreSQL tout en conservant les caractéristiques de performance analytique de DuckDB.

Les E/S asynchrones sont une technique où les opérations de lecture de données ne bloquent pas le thread de traitement principal. Au lieu de cela, le système émet des demandes de lecture et continue d'autres travaux en attendant que les données arrivent du disque ou du stockage réseau. Ceci est particulièrement critique pour les environnements cloud-native où les résident souvent dans un stockage d'objets plutôt que sur des disques locaux. En maintenant plusieurs demandes de lecture en vol, la base de données peut utiliser la bande passante disponible plus efficacement, réduisant le temps d'attente pour la récupération des données lors de requêtes analytiques complexes.

Pourquoi c'est important

Pour les équipes d'ingénierie gérant des plateformes d'analyse auto-hébergées, la capacité de déployer DuckDB comme serveur ouvre de nouvelles possibilités architecturales. Cela permet un service de données centralisé sans migrer vers des systèmes de base de données plus lourds et plus complexes. L'ergonomie améliorée de l'instruction CONNECT simplifie la gestion des sources de données distantes, rendant plus facile la construction de systèmes de requêtes fédérées qui extraient des données de PostgreSQL, MySQL ou d'autres instances DuckDB. Cela réduit le besoin de pipelines ETL complexes lorsque l'accès en temps réel aux données distribuées est requis.

Les gains de performance issus des E/S asynchrones impactent directement le coût et l'efficacité pour les entreprises stockant de grands jeux de données dans le stockage d'objets cloud. Des temps de requête plus rapides signifient moins de temps de calcul consommé par analyse, ce qui peut entraîner des économies significatives sur les factures d'infrastructure cloud. De plus, la prise en charge de première classe du type VARIANT répond à un point de douleur courant dans l'ingénierie des données moderne : la gestion des données de journal semi-structurées ou des réponses API. En traitant ces données efficacement au sein du magasin colonnaire, les équipes peuvent éviter la pénalité de performance liée à l'analyse des chaînes JSON au moment de la requête.

La sécurité opérationnelle et le contrôle sont renforcés par la capacité d'héberger des dépôts d'extensions privés. Les organisations qui développent des outils internes personnalisés ou des connecteurs de données sensibles peuvent désormais les distribuer avec la même facilité et la même sécurité que les extensions officielles. Cela garantit que seul du code vérifié s'exécute dans les environnements de production, atténuant les risques liés à la chaîne d'approvisionnement associés aux plugins tiers. Le calendrier de support étendu pour la version 1.5 offre également une fenêtre sûre pour les équipes afin de tester et valider leurs migrations sans pression immédiate.

Ce que vous pouvez faire

• Testez la nouvelle version dans un système fantôme avant de mettre à niveau les environnements de production pour identifier d'éventuels problèmes de compatibilité avec les fichiers de base de données existants.
• Évaluez le protocole Quack pour les cas d'utilisation nécessitant un accès concurrent aux données DuckDB depuis plusieurs applications ou services.
• Effectuez des benchmarks de performance des requêtes sur le stockage d'objets distant pour mesurer l'impact des E/S asynchrones sur vos charges de travail spécifiques.
• Refactorisez la logique de traitement JSON pour tirer parti du type VARIANT afin d'améliorer la compression et la vitesse de requête sur les données semi-structurées.
• Configurez un dépôt d'extensions privé si votre équipe maintient des extensions DuckDB personnalisées, en veillant à ce qu'elles soient signées et vérifiées.
• Consultez le guide de migration pour les changements cassants, en particulier concernant la compatibilité du format de stockage et les différences de comportement de l'analyseur.