Dans un monde où l’analyse de données rime souvent avec grappes de serveurs et infrastructures lourdes à administrer, un petit outil fait beaucoup parler de lui : DuckDB. Sa proposition tient en une phrase : la puissance d’une base analytique, sans serveur, dans un simple fichier. On le surnomme parfois « le SQLite de l’analytique », et la comparaison est juste.
Le principe : zéro serveur
DuckDB ne s’installe pas au sens classique, ne se configure pas, ne tourne pas en arrière-plan comme un service. C’est une bibliothèque qui s’exécute directement dans votre processus, qu’il s’agisse d’un script Python, d’un carnet de notes ou d’une application. Pas de serveur à administrer, pas de connexion réseau, pas de coût d’infrastructure, pas de port à sécuriser. La base, c’est un fichier que l’on peut copier, versionner, sauvegarder et partager comme n’importe quel document.
Pensé pour l’analytique
La différence avec SQLite est fondamentale et mérite d’être comprise. SQLite est optimisé pour les transactions : de nombreuses petites lectures et écritures fréquentes, typiques d’une application. DuckDB est optimisé pour l’analytique : agréger des millions de lignes, croiser plusieurs tables, calculer des statistiques sur de gros volumes. Il y parvient grâce à un stockage en colonnes et à une exécution vectorisée, qui traitent les données par lots plutôt que ligne par ligne, exactement comme les grands entrepôts, mais sur votre machine.
Ce qui séduit
- Il interroge directement des fichiers (CSV, Parquet, JSON) sans étape d’import préalable, ce qui fait gagner un temps considérable au quotidien.
- Il avale des volumes supérieurs à la mémoire vive disponible, en s’appuyant intelligemment sur le disque quand c’est nécessaire.
- Il s’intègre nativement avec les outils de science des données, sans friction ni colle à écrire.
- Il est rapide, parfois spectaculairement, sur des tâches qui imposaient jusqu’ici une grappe entière.
Ce qu’il n’est pas
DuckDB n’est pas une base de production multi-utilisateurs, et il ne prétend pas l’être. Il n’est pas conçu pour que des centaines de clients écrivent en même temps, ni pour servir de socle à une application web à fort trafic. Ce n’est tout simplement pas son rôle. Il excelle en analyse locale, en préparation de données, en prototypage, en tests et en traitement par lots.
Un cas d’usage typique
Imaginez un analyste qui reçoit chaque mois plusieurs fichiers de plusieurs gigaoctets à croiser. Avec une approche classique, il faudrait charger ces données dans un entrepôt, attendre, puis interroger. Avec DuckDB, il pointe directement les fichiers, écrit son SQL, obtient le résultat en quelques secondes, le tout depuis son ordinateur portable, sans rien provisionner. C’est ce genre de scénario qui explique l’enthousiasme.
Pourquoi c’est important
DuckDB illustre une tendance de fond salutaire : tout n’a pas besoin d’être distribué. Pendant des années, le réflexe a été de monter une grappe dès qu’on prononçait le mot « big data », avec la complexité et le coût que cela implique. Or la grande majorité des jeux de données réels tiennent largement sur une seule machine moderne. Avant de provisionner une grappe, posez-vous la question : et si un simple fichier suffisait ?