Pourquoi DuckDB est mon premier choix pour le traitement des données

 (robinlinacre.com)
30 points par GN⁺ 2026-01-18 | 2 commentaires | Partager sur WhatsApp
  • DuckDB est un moteur SQL open source qui permet de traiter rapidement et simplement de grands volumes de données tabulaires sur une seule machine, et il est aujourd’hui largement utilisé en data engineering
  • L’installation est simple, sans dépendances, et il peut être exécuté immédiatement dans un environnement Python, ce qui le rend adapté à la CI et à l’automatisation des tests
  • Grâce à l’optimisation des requêtes analytiques, il peut offrir des performances jusqu’à 1 000 fois supérieures à SQLite ou Postgres, tout en permettant d’interroger directement différents formats de fichiers (csv, parquet, json)
  • Avec une syntaxe SQL conviviale (EXCLUDE, COLUMNS, QUALIFY, chaînage de fonctions, etc.) et une API Python, il permet de développer efficacement des pipelines complexes
  • Grâce à la conformité ACID, aux UDF haute performance et à l’extension d’intégration PostgreSQL, il s’impose comme une alternative aux lakehouses pour les données de taille intermédiaire

Vue d’ensemble de DuckDB

  • DuckDB est un moteur SQL in-process axé sur l’optimisation des requêtes analytiques
    • Il s’exécute à l’intérieur de l’application, sans serveur séparé, et ne nécessite aucun service externe comme Postgres
    • Il est spécialisé dans les opérations massives de jointure et d’agrégation, et peut offrir des performances jusqu’à 100 à 1 000 fois supérieures à celles des moteurs orientés transactions (OLTP)
  • Son principal cas d’usage est le traitement par lots (batch processing), en lisant directement depuis le disque de gros fichiers csv, parquet, json, etc.
  • Il peut aussi servir à l’exploration légère de données, par exemple pour interroger rapidement un fichier CSV en ligne de commande

Principales caractéristiques

  • Vitesse

    • DuckDB est l’un des moteurs open source de traitement de données les plus rapides, et figure régulièrement en tête des benchmarks
    • Comparé à Polars, DataFusion, Spark ou Dask, DuckDB domine sur les petits volumes, tandis que Spark et Dask restent compétitifs à très grande échelle

  • Installation simple et absence de dépendances

    • DuckDB est distribué sous la forme d’un binaire précompilé unique et peut être installé immédiatement en Python avec pip install duckdb
    • Son absence de dépendances rend l’installation bien plus simple que celle de grands frameworks comme Spark
    • Combiné à uv, il est possible de préparer un environnement Python en moins d’une seconde

  • CI et tests

    • Grâce à son démarrage rapide et à sa légèreté, il est bien adapté aux environnements de CI et de test pour les pipelines de données
    • Là où les tests basés sur Spark étaient auparavant lents et complexes, DuckDB facilite à la fois la configuration de l’environnement et le maintien de la cohérence avec la production

  • Expérience d’écriture SQL

    • DuckDB permet de rédiger du SQL et de valider la syntaxe rapidement
    • Il est plus adapté que le mode local de Spark ou AWS Athena à l’exécution immédiate et au développement itératif
    • Il fournit une interface avec autocomplétion

  • Syntaxe SQL conviviale

    • DuckDB inclut de nombreuses extensions SQL conviviales
      • prise en charge de EXCLUDE, COLUMNS, QUALIFY, des modificateurs d’agrégation pour fonctions de fenêtre et du chaînage de fonctions (first_name.lower().trim())
    • Ces fonctionnalités permettent d’effectuer de manière concise des sélections et transformations de colonnes complexes

  • Prise en charge de multiples formats de fichiers

    • Il permet d’interroger directement des données depuis S3, des URL web ou des fichiers locaux
    • Il propose des options de typage strict pour les CSV, afin d’éviter les erreurs dues à des données d’entrée non structurées

  • API Python

    • En Python, il est possible de définir étape par étape des pipelines basés sur des CTE, et d’inspecter facilement les données à chaque étape
      • les appels à duckdb.sql() permettent de chaîner les requêtes SQL
      • grâce à l’exécution différée (lazy execution), on peut vérifier les résultats intermédiaires sans perte de performance
    • Le test des fonctions à chaque étape est possible, ce qui améliore l’efficacité des tests en CI

  • Conformité ACID

    • DuckDB offre une garantie ACID complète, même pour les traitements sur de gros volumes de données
    • Cette propriété en fait une alternative intermédiaire à des formats de lakehouse comme Iceberg ou Delta Lake

  • UDF haute performance et extensions communautaires

    • Il est possible d’écrire des fonctions définies par l’utilisateur (UDF) haute performance en C++
    • Les Community Extensions permettent d’installer immédiatement des extensions via des commandes comme INSTALL h3 FROM community
      • Exemple : prise en charge de l’indexation hexagonale (h3) pour les données géospatiales

  • Documentation

    • Toute la documentation est fournie dans un seul fichier Markdown, ce qui facilite son utilisation pour l’entraînement de LLM ou la recherche dans un éditeur de code
    • La fonctionnalité de repli de code permet de copier facilement uniquement les sections nécessaires

Utilisation concrète et effets

  • Dans le projet open source Splink, l’adoption de DuckDB comme backend par défaut a permis
    • de réduire les problèmes rencontrés par les utilisateurs, d’accélérer le travail et de simplifier le développement et les tests des fonctionnalités

Extensions à suivre de près

  • PostgreSQL Extension : permet de connecter et d’interroger directement une base de données Postgres depuis DuckDB
  • pg_duckdb : embarque le moteur DuckDB à l’intérieur de Postgres pour combiner traitement transactionnel et analytique
    • après de futures améliorations de l’optimisation des index Postgres et du filter push-up, une adoption plus large est possible

À lire aussi

2 commentaires

 
kaydash 2026-01-18

C'est assez ironique d'utiliser Parquet, conçu pour le traitement distribué, dans le but de le traiter sur une seule machine.
 
GN⁺ 2026-01-18
Réactions sur Hacker News

  • Il y a plein de raisons pour lesquelles j’aime DuckDB
    Il prend en charge les fichiers .parquet, .json et .csv, et permet la lecture par glob avec quelque chose comme select * from 'tsa20*.csv', ce qui permet de traiter des centaines de fichiers comme s’il n’y en avait qu’un
    Même si les schémas diffèrent, on peut les fusionner facilement avec union_by_name, et le parseur CSV infère correctement les types automatiquement
    La version WebAssembly fait 2 Mo, la CLI 16 Mo, donc c’est extrêmement léger
    Ça permet de l’intégrer directement dans un produit. Par exemple comme Malloy
    Malloy, c’est un peu la version pour techniciens de PowerBI ou Tableau, avec un modèle sémantique qui aide l’IA à écrire de meilleures requêtes. On a l’impression que ça rend SQL 10 fois plus facile à utiliser

    • Le support CSV de DuckDB a complètement changé ma façon d’explorer les données
      Avant, je passais du temps à essayer de comprendre le schéma d’abord, alors que maintenant je charge les données, j’écris des requêtes d’exploration, je vérifie mes hypothèses, puis je répète les étapes de nettoyage, transformation et création de tables
      Ça me permet d’aller beaucoup plus vite et plus loin, et de repérer rapidement les impasses pour éviter de perdre du temps
      J’ai entendu dire qu’il existait un article sur le fonctionnement du parseur CSV et des idées d’amélioration futures, mais je ne l’ai pas encore retrouvé
    • J’ai beaucoup utilisé ClickHouse récemment, et il partage beaucoup des mêmes avantages que DuckDB
      En particulier, l’ingestion de Parquet et JSON est pratique, et clickhouse-local ressemble au concept d’embarquer DuckDB
      Avec la syntaxe SELECT ... FROM s3Cluster(...), on peut faire de l’ingestion par wildcard depuis un bucket S3, avec traitement distribué sur les nœuds du cluster
      Il semble aussi prendre en charge schema_inference_mode
      ClickHouse a également implémenté une fonctionnalité similaire à union_by_name
      Documentation associée : fonction s3Cluster, schema inference, PR #55892
    • J’ai créé Shaper, qui combine requêtes de données et visualisation dans l’esprit des idées de Malloy
      Mais Shaper utilise SQL au lieu d’un langage séparé
      Il permet de créer des dashboards uniquement en SQL sur la base de DuckDB
      Shaper GitHub
    • J’ai créé ZenQuery et j’utilise DuckDB en interne
      Les performances sont impressionnantes, et la détection automatique du schéma fonctionne correctement dans la plupart des cas
      Le LLM génère le bon SQL à partir de requêtes en langage naturel
    • C’est vraiment une excellente introduction
      J’avais l’habitude de faire des imports manuels avec SQLite, et DuckDB a rendu tout ça bien plus simple

  • Moi aussi, j’utilise DuckDB très régulièrement
    Je travaille avec des scientifiques qui étudient l’environnement côtier en Colombie-Britannique, et nous traitons d’énormes volumes de données, depuis les observations glaciaires jusqu’aux données de drones sous-marins
    Nous avons choisi DuckDB comme moteur d’un nouvel outil de transformation des données de biodiversité, avec pour objectif de convertir et valider les données selon le standard Darwin Core
    Nous créons dynamiquement des tables DuckDB à partir du schéma et nous importons les données. En cas d’échec, l’outil indique la raison ligne par ligne
    Les transformations et la validation sont elles aussi entièrement exécutées dans DuckDB
    Ça nous a permis de créer une application bien plus rapide, plus puissante et capable de s’exécuter dans le navigateur
    Les chercheurs de terrain peuvent même l’utiliser hors ligne dans le navigateur d’un iPad
    Avec DuckDB, on a cette confiance que SQL prend en charge le gros du travail
    Ce qui manque en sûreté de typage est compensé par le parsing et les tests
    L’objectif du projet est de permettre aux scientifiques d’analyser des données de biodiversité et de génomique avec un outil commun, puis de les publier dans des dépôts publics

    • Je me demande dans quel format sont les jeux de données existants
      Dans le traitement de données scientifiques, je manipule souvent du HDF5, mais DuckDB ne le prend pas en charge nativement
      Les extensions existantes étaient lentes et incomplètes, donc j’ai créé une nouvelle extension avec des templates C++
      Je cherche des gens intéressés par une collaboration
    • Je me demande quels seraient les avantages d’utiliser Polars pour la même tâche
      Personnellement, je trouve la syntaxe de Polars bien plus confortable que SQL, donc j’hésite à savoir si DuckDB vaut le coup d’être essayé

  • Nous faisons l’analytique et le traitement des feeds de Bluesky avec DuckDB
    Pour obtenir rapidement les résultats, nous utilisons l’interface Apache Arrow et SQG pour générer directement du code à partir des requêtes SQL DuckDB

    • Je serais curieux de connaître votre stack technique. J’aimerais aussi savoir s’il existe un article sur votre architecture interne. L’outil HN est impressionnant lui aussi

  • Je voudrais présenter le projet Java manifold-sql
    Il permet d’écrire du DuckDB SQL inline de manière type-safe
    On peut mettre SQL directement dans le code et parcourir les résultats avec .fetch(), ce qui reste propre sans couche intermédiaire

  • L’argument de l’auteur est valable pour le traitement de données de base, mais
    l’idée que « la plupart des données tabulaires peuvent être traitées sur une seule machine » reste discutable
    Dès qu’on commence à faire de l’expansion, des pivots ou de l’enrichissement, on se retrouve vite avec des OOM (out of memory)
    Et l’affirmation selon laquelle « SQL devrait devenir le premier choix de la nouvelle ingénierie des données » ne convient pas forcément aux analyses complexes

    • L’auteur ici
      Les API dataframe comme Polars ou pandas ont aussi beaucoup d’avantages, mais le problème, c’est que l’écosystème n’est pas standardisé et qu’il faut souvent réécrire les pipelines
      La plupart des données font moins de 10 Go, donc elles peuvent très bien être traitées sur une seule machine
      Spark est souvent utilisé de façon excessive
      Mon point de vue, c’est : « essayez d’abord avec DuckDB ». Pour les cas simples, c’est rapide et efficace
    • Pour les analyses avancées comme le ML ou la visualisation, les dataframes sont plus adaptés
      SQL est bien pour les pipelines simples, mais la lisibilité dépend des personnes
      Moi, je trouve l’approche dataframe bien plus lisible
    • SQL reste facile à apprendre, et la modélisation des données se fait encore majoritairement en SQL
      Côté ingestion, on voit beaucoup de Python ou Scala, mais SQL ne disparaîtra pas
    • Je traite 500 Go de données Parquet avec DuckDB, et ça reste fluide et rapide même sur un desktop avec 50 Go de RAM
      Les OOM ne semblent poser problème que dans des cas extrêmes
    • Polars possède lui aussi la plupart de ces avantages, et prend même en charge des backends GPU et distribués
      Autant DuckDB attire l’attention, autant Polars reste sous-estimé

  • Je fais beaucoup de traitement de données, et j’utilise surtout Polars
    C’est extrêmement rapide, et il y a beaucoup de fonctions, comme dans pandas, qui sont difficiles à exprimer en SQL
    On peut aussi utiliser directement des fonctions Python
    Même si DuckDB avait les mêmes performances, j’hésiterais à cause des limites d’expression de SQL

    • D’après mon expérience, DuckDB était bien plus rapide et concis
      C’est autonome, donc très simple à installer, avec presque aucun tuning ni courbe d’apprentissage

  • J’ai chargé avec DuckDB des fichiers Excel mal formatés générés par un mainframe,
    et avec l’option all_varchar, tout a été chargé en moins d’une seconde
    Excel est toujours en train d’ouvrir le fichier

  • DuckDB est excellent, mais le chargement dynamique d’extensions entre en conflit avec la signature de code, ce qui complique son usage dans des applications commerciales
    Et l’extension spatiale utilise des composants LGPL, ce qui pose des questions de licence
    Ce serait bien de pouvoir composer uniquement les fonctionnalités nécessaires au niveau des packages, comme avec Apache Arrow
    Par exemple : transfert de tableaux à plusieurs Go/s via HTTP avec Arrow Flight, partage de fichiers avec Arrow IPC, lecture de Parquet en ajoutant juste un trait séparé
    Le système de types SQL de DuckDB diffère de celui d’Arrow, ce qui peut créer des problèmes d’incompatibilité de types
    Arrow fournit des bibliothèques natives dans la plupart des langages

  • Je me demande s’il permet de récupérer rapidement une page filtrée avec un WHERE sur une table unique
    contenant des dizaines de milliards de transactions et 30 colonnes
    Dans Postgres, même un simple count(*) prend beaucoup de temps

    • À cette échelle, ça devrait quand même se faire en quelques secondes avec DuckDB
      Les seuls cas lents que j’ai vus concernaient des jointures complexes ou des glob sur de nombreux fichiers
    • Pour accélérer les count, un cache périodique pourrait être plus utile qu’un index
      Si les conditions WHERE sont de simples couples colonne-valeur, ça devrait être assez rapide

  • DuckDB n’est pas seulement une base rapide, il offre aussi une excellente expérience développeur (devx)
    Il est facile de démarrer, ce qui permet à l’écosystème de s’étendre rapidement
    L’intégration Web/WASM est également impressionnante
    J’aimerais voir plus de petits moteurs de ce type apparaître, pour continuer à stimuler la concurrence et l’innovation