DuckDB : la base analytique embarquée qui bouscule le Data Warehouse

Faut-il vraiment démarrer un cluster Spark ou payer un Data Warehouse Cloud pour analyser quelques dizaines de gigaoctets de fichiers Parquet ? Pendant des années, la réponse par défaut des équipes Data a été oui, faute d'alternative légère. Aujourd'hui, un moteur SQL analytique qui s'installe en une ligne et s'exécute dans le processus de votre script change la donne : DuckDB.

Né au CWI d'Amsterdam (le centre de recherche national néerlandais en mathématiques et informatique) et publié sous licence MIT, DuckDB est souvent présenté comme le « SQLite de l'analytique ». Comme SQLite, il n'y a ni serveur à administrer, ni service à déployer : la base vit dans votre processus Python, R ou dans un simple binaire en ligne de commande. Contrairement à SQLite, il est conçu pour les requêtes analytiques (agrégations, jointures, fonctions de fenêtre) sur de gros volumes, grâce à un stockage en colonnes et à une exécution vectorisée. Sa version 1.0 est sortie en juin 2024 et son adoption chez les Data Engineers et les Analytics Engineers n'a cessé de croître depuis.

Dans cet article, nous allons explorer l'architecture de DuckDB et ce qui explique ses performances, puis son utilisation depuis Python et la ligne de commande, son système d'extensions, l'écosystème MotherDuck et le format DuckLake, avant de voir dans quels cas il remplace (ou non) Spark et un Data Warehouse Cloud.

Qu'est-ce que DuckDB ?

DuckDB est un système de gestion de base de données analytique embarqué (on parle de moteur OLAP in-process). Il s'exécute dans le même processus que l'application qui l'appelle, sans communication réseau ni démon séparé. Les données peuvent être stockées dans un fichier unique .duckdb, ou rester là où elles se trouvent : fichiers locaux, objets sur un bucket S3, DataFrames déjà chargés en mémoire.

Ce dernier point est la vraie rupture. Là où un Data Warehouse classique impose de charger les données dans son propre stockage avant de les interroger, DuckDB sait requêter les fichiers directement :

• Parquet : lecture en colonnes avec projection et filtrage poussés dans le fichier, ce qui évite de lire ce qui n'est pas utile (voir notre article sur Apache Parquet).
• CSV et JSON : détection automatique du schéma, des séparateurs et des types.
• Tables Iceberg : lecture, et écriture selon le catalogue utilisé, grâce à l'extension dédiée au format Apache Iceberg.
• Autres sources : Excel, bases PostgreSQL ou MySQL attachées, DataFrames pandas et Polars, tables Arrow.

Le dialecte SQL est très proche de celui de PostgreSQL, avec de nombreuses améliorations ergonomiques : GROUP BY ALL, SELECT * EXCLUDE (colonne), FROM table sans SELECT, listes et structures imbriquées, QUALIFY pour filtrer sur des fonctions de fenêtre. Un Analytics Engineer retrouve donc immédiatement ses repères, et l'outil se branche naturellement avec des frameworks de transformation comme dbt ou SQLMesh, qui disposent tous deux d'un connecteur DuckDB.

L'architecture qui explique ses performances

Savoir que DuckDB est rapide ne suffit pas : comprendre pourquoi permet de savoir quand lui faire confiance.

Stockage en colonnes et exécution vectorisée

Les bases transactionnelles stockent les données ligne par ligne, ce qui est efficace pour lire ou modifier un enregistrement complet. Une requête analytique, elle, lit quelques colonnes sur des millions de lignes. DuckDB organise donc ses données en colonnes, ce qui réduit les lectures, améliore la compression et permet d'appliquer la même opération à une série de valeurs contiguës.

Le moteur traite ensuite ces colonnes par vecteurs, des lots de quelques milliers de valeurs (2 048 par défaut). Ce modèle d'exécution vectorisée évite le coût d'interprétation ligne à ligne des moteurs traditionnels et tire parti des caches du processeur et des instructions SIMD. Il se situe entre le traitement ligne par ligne (trop lent) et la matérialisation de colonnes entières (trop gourmande en mémoire).

Parallélisme et traitement hors mémoire

DuckDB répartit automatiquement le travail sur tous les cœurs disponibles de la machine : une agrégation ou une jointure est découpée en morceaux traités en parallèle, sans configuration. Lorsque les données intermédiaires dépassent la mémoire, le moteur peut déborder sur le disque (traitement dit out-of-core) pour les opérateurs principaux comme les tris, les agrégations et les jointures. C'est ce qui permet d'analyser sur un ordinateur portable un jeu de données plus gros que sa RAM, avec une dégradation progressive plutôt qu'une erreur.

Transactions et fichier unique

Malgré sa vocation analytique, DuckDB offre des transactions ACID avec isolation par versions (MVCC). Un fichier .duckdb accepte un seul processus en écriture à la fois, mais plusieurs en lecture seule. Cette contrainte est volontaire : elle simplifie le moteur, et elle définit aussi le périmètre d'usage de l'outil, comme nous le verrons dans la dernière section.

Ce comparatif montre que DuckDB ne cherche pas à remplacer toutes les bases : il occupe un créneau précis, l'analytique de haute performance sans infrastructure, que ni les bases transactionnelles ni les entrepôts cloud ne couvrent à ce prix de complexité.

Utiliser DuckDB avec Python et la CLI

L'une des raisons de son succès tient à sa prise en main : une installation et une première requête suffisent pour être productif.

Depuis Python

L'installation se fait avec pip install duckdb. Le code suivant interroge un ensemble de fichiers Parquet et récupère le résultat dans un DataFrame pandas :

import duckdb

# Connexion en mémoire (utiliser duckdb.connect("analyse.duckdb") pour persister)
con = duckdb.connect()

# Requête directe sur un dossier de fichiers Parquet, sans chargement préalable
ca_par_pays = con.sql("""
    SELECT pays, SUM(montant) AS chiffre_affaires
    FROM read_parquet('ventes/*.parquet')
    WHERE date_commande >= DATE '2026-01-01'
    GROUP BY ALL
    ORDER BY chiffre_affaires DESC
""").df()

print(ca_par_pays.head())

La méthode .sql() renvoie une relation évaluée paresseusement : la requête n'est exécutée que lorsque l'on demande le résultat, par exemple avec .df() pour pandas, .pl() pour Polars, .arrow() pour Arrow ou .fetchall() pour des tuples Python.

DuckDB sait aussi interroger un DataFrame présent dans l'espace de noms Python, simplement en utilisant son nom de variable dans la requête. Cela permet de mélanger code pandas et SQL sans copie coûteuse :

import duckdb
import pandas as pd

commandes = pd.read_csv("commandes.csv")

# Le DataFrame est référencé directement par le nom de la variable
resultat = duckdb.sql("""
    SELECT client_id, COUNT(*) AS nb_commandes
    FROM commandes
    GROUP BY client_id
    HAVING COUNT(*) > 5
""").df()

Depuis la ligne de commande

Le binaire duckdb fournit un shell interactif et un mode non interactif, très pratique pour explorer un fichier en quelques secondes ou intégrer une étape dans un script :

# Explorer un fichier sans rien charger
duckdb -c "DESCRIBE SELECT * FROM 'ventes.parquet'"

# Convertir un CSV en Parquet compressé
duckdb -c "COPY (SELECT * FROM 'export.csv') TO 'export.parquet' (FORMAT parquet, COMPRESSION zstd)"

# Ouvrir une base persistante en mode interactif
duckdb analyse.duckdb

Pour un Data Engineer, cette simplicité change le quotidien : inspecter un export, vérifier la qualité d'une extraction ou convertir des formats ne nécessite plus de lancer un notebook Spark ni de provisionner un entrepôt.

À lire : découvrez notre formation Data Engineer

Extensions, MotherDuck et DuckLake

Le cœur de DuckDB reste volontairement compact. Les fonctionnalités supplémentaires sont fournies par des extensions, téléchargées à la demande avec INSTALL puis activées avec LOAD.

Un système d'extensions riche

Parmi les extensions les plus utilisées figurent :

• httpfs : lecture et écriture de fichiers distants via HTTP et S3 (ou stockages compatibles), avec gestion des identifiants par CREATE SECRET.
• iceberg : lecture de tables Apache Iceberg, et écriture via un catalogue REST.
• delta : lecture de tables Delta Lake.
• postgres et mysql : attachement de bases relationnelles pour les interroger ou les copier.
• spatial : types et fonctions géographiques.
• json et parquet : intégrées au moteur, elles couvrent les formats les plus courants.

Voici comment interroger un fichier Parquet sur un bucket S3 puis une table Iceberg :

INSTALL httpfs;
LOAD httpfs;

-- Identifiants S3 récupérés via la chaîne de fournisseurs AWS habituelle
CREATE SECRET s3_secret (TYPE s3, PROVIDER credential_chain);

SELECT COUNT(*) FROM read_parquet('s3://mon-bucket/ventes/2026/*.parquet');

INSTALL iceberg;
LOAD iceberg;

-- Lecture d'une table Iceberg à partir de son emplacement
SELECT * FROM iceberg_scan('s3://mon-bucket/warehouse/commandes') LIMIT 10;

L'accès aux données du Data Lake se fait donc en SQL, depuis un simple poste de travail, avec les mêmes identifiants que le reste de votre chaîne.

MotherDuck : DuckDB dans le cloud

DuckDB étant embarqué, deux limites apparaissent dès qu'une équipe grandit : le partage des données entre collègues et l'exécution sur des volumes qui dépassent la machine locale. MotherDuck est le service managé construit autour de DuckDB pour y répondre. Il fournit des bases hébergées, un partage entre utilisateurs et une exécution hybride, où une partie de la requête s'exécute sur le poste local et l'autre dans le cloud.

La connexion s'effectue avec une seule instruction depuis le client DuckDB habituel, ATTACH 'md:', après avoir renseigné un jeton d'accès. Le même SQL fonctionne donc en local et dans le cloud, ce qui évite de réécrire le code lorsque l'on change d'échelle.

DuckLake : un format de lakehouse piloté par le SQL

Les formats de tables ouverts comme Iceberg ou Delta Lake stockent leurs métadonnées dans des fichiers (manifestes, journaux de transactions) parmi les données. DuckLake, proposé par les créateurs de DuckDB, adopte l'approche inverse : les données restent dans des fichiers Parquet sur un stockage objet, mais les métadonnées sont stockées dans une base SQL (DuckDB, SQLite ou PostgreSQL par exemple). Cela simplifie la gestion des transactions, des instantanés (snapshots) et des modifications de schéma, avec un catalogue interrogeable en SQL.

La spécification a atteint sa version 1.0 au printemps 2026. Son utilisation passe par l'extension ducklake :

INSTALL ducklake;
LOAD ducklake;

-- Les métadonnées vont dans un fichier local, les données dans le dossier indiqué
ATTACH 'ducklake:metadata.ducklake' AS lac (DATA_PATH 'donnees/');

CREATE TABLE lac.commandes AS
SELECT * FROM read_parquet('ventes/*.parquet');

-- Le format conserve l'historique des instantanés
SELECT * FROM lac.snapshots();

DuckLake est encore jeune face à Iceberg, dont l'écosystème d'outils (Spark, Trino, Flink, entrepôts cloud) reste bien plus large. Il est plus pertinent pour les équipes qui s'appuient déjà sur DuckDB, ou qui souhaitent un lakehouse sans la complexité d'un catalogue dédié. L'extension Iceberg propose par ailleurs une fonction pour copier les métadonnées d'un catalogue Iceberg vers DuckLake, ce qui facilite l'expérimentation.

À découvrir : notre formation Data Engineer

DuckDB face à Spark et au Data Warehouse Cloud

Reste la question centrale : faut-il remplacer ses outils actuels ? La réponse dépend de la taille des données et du mode d'usage.

Quand DuckDB remplace Spark

Un cluster Apache Spark se justifie lorsque les données dépassent ce qu'une seule machine peut traiter. Or une machine actuelle dispose de dizaines de cœurs et de centaines de gigaoctets de mémoire, et beaucoup de traitements « Big Data » portent en réalité sur des volumes de quelques dizaines à quelques centaines de gigaoctets. Dans ce cas, DuckDB offre des avantages concrets :

• Pas d'infrastructure : aucun cluster à provisionner, démarrer et éteindre.
• Latence de démarrage quasi nulle : une requête s'exécute en quelques secondes, là où un job Spark prend du temps rien qu'à s'initialiser.
• Tests et CI simplifiés : les transformations SQL se testent localement, sur des échantillons, sans environnement distant.
• Développement plus rapide : la boucle écriture, exécution, vérification se fait sur le poste du développeur.

Quand DuckDB remplace (ou complète) le Data Warehouse Cloud

Face à Snowflake ou BigQuery, DuckDB ne vise pas le même rôle. Il excelle pour l'exploration ponctuelle, le prototypage, les transformations intermédiaires sur Parquet, les pipelines de petite et moyenne taille ou les applications qui embarquent de l'analytique. Il peut aussi servir à réduire la facture d'un entrepôt, en déportant sur des fichiers les traitements lourds qui n'ont pas besoin d'un cluster.

Pour autant, certains besoins restent hors de son périmètre :

• Concurrence élevée : de nombreux utilisateurs ou applications qui écrivent en simultané dans la même base.
• Gouvernance centralisée : contrôle d'accès fin, audit et partage à l'échelle de l'entreprise, que fournissent les entrepôts managés.
• Volumes à l'échelle du téraoctet à grande vitesse : au-delà de ce qu'une machine unique peut raisonnablement porter.
• Charges transactionnelles : DuckDB n'est pas conçu pour remplacer une base OLTP comme PostgreSQL.

Dans la pratique, les équipes combinent souvent les deux approches : DuckDB pour le développement, les tests et les traitements légers, et un Data Warehouse pour la diffusion à grande échelle et la gouvernance. Le choix de l'outil devient une question d'échelle et d'usage, plutôt qu'un réflexe.

Conclusion

DuckDB a prouvé qu'un moteur analytique performant n'a pas besoin de serveur. Son stockage en colonnes, son exécution vectorisée et son parallélisme automatique permettent à un simple poste de travail de traiter des volumes que l'on réservait autrefois à des clusters. Sa capacité à interroger directement Parquet, CSV et tables Iceberg supprime une grande partie des étapes de chargement qui alourdissent les pipelines.

L'écosystème qui se construit autour du moteur, avec ses extensions, MotherDuck pour le partage et le cloud, et DuckLake pour le lakehouse, montre que l'outil dépasse désormais le cadre du simple utilitaire local. Il ne remplace ni Spark pour les très gros volumes ni un Data Warehouse pour la gouvernance et la forte concurrence, mais il redéfinit le seuil à partir duquel ces solutions deviennent nécessaires.

Pour un Data Engineer ou un Analytics Engineer, maîtriser DuckDB est désormais une compétence différenciante : elle permet de choisir l'infrastructure la plus simple pour chaque problème, de réduire les coûts et d'accélérer le développement. Savoir quand ne pas déployer un cluster devient, lui aussi, une marque d'expertise.