Pourquoi DuckDB n'est pas une solution miracle

DuckDB a fait beaucoup de bruit dans l'écosystème data ces deux dernières années. Une base de données SQL colonnaire ultra-rapide, sans dépendances externes, fonctionnant directement en Python ou en CLI ? C'est séduisant. Mais après six mois d'utilisation en production sur des pipelines analytiques variés, je dois être honnête : DuckDB est excellent pour certains cas d'usage précis, catastrophique pour d'autres. Et c'est rarement ceux qu'on croit.

Le marché crée des attentes démesurées autour de chaque nouvelle technologie. DuckDB n'échappe pas à cette règle. Je vois régulièrement des équipes l'adopter comme remède universel aux problèmes de performance, sans comprendre ses vraies forces et surtout ses vrais murs. Cet article repose sur des retours concrets, y compris sur les décisions que nous avons dû réviser.

DuckDB brille dans son écosystème restreint

Commençons par les faits : DuckDB excelle quand vous avez des fichiers Parquet ou CSV volumineux en local ou sur S3, que vous voulez requêter directement sans infrastructure complexe. Les jointures multi-fichiers sont rapides, l'interface SQL est claire, et c'est fantastique pour du prototypage analytique. Aucune discussion possible là-dessus.

Nous l'avons adopté pour nos exports de data warehouse—fichiers Parquet de 5-50 Go queried par des data scientists. Avant : chargement en Pandas très gourmand en RAM. Avec DuckDB : réponses en secondes, consommation RAM raisonnable. Cas d'usage résolu.

Mais voilà : ce scénario représente peut-être 20% des besoins réels en data. Pour tout le reste—APIs, transactionnel, real-time, architectures multi-clients—DuckDB devient rapidement handicapant.

Le problème critique : l'absence de vrai serveur et de concurrence

DuckDB fonctionne en embedded database. C'est sa philosophie core et aussi sa plus grande limitation en production. Un seul processus Python, Node ou Rust accède à un fichier .duckdb à la fois. Pas de vrai serveur réseau, pas de gestion native des connexions concurrentes, pas de locking distribué.

Nous avons tenté d'utiliser DuckDB comme backend pour un service interne de requêtes analytiques. Plusieurs workers Python se connectant au même fichier .duckdb. Résultat : contentions fréquentes, timeouts sporadiques, aucun contrôle de concurrence convenable. DuckDB a des mécanismes basiques (WAL, in-process locking) mais ils ne sont pas conçus pour du vrai partage réseau.

Il existe DuckDB Labs qui propose un serveur expérimental, mais c'est loin d'être production-ready et l'écosystème outillage reste minimal. Si vous avez même 5 clients simultanés, regardez ailleurs. PostgreSQL, même avec PgStac pour l'analytique, sort vainqueur.

Le piège de la mémoire et des datasets volumineux

DuckDB annonce une gestion mémoire « intelligente » avec spill sur disque. Techniquement vrai. En pratique ? Moins glorieux. Sur des agrégations complexes sur des datasets dépassant votre RAM disponible, le spill devient catastrophique en termes de latence.

Scenario réel : dataset 200 Go, 64 Go RAM disponible, requête avec trois jointures et un GROUP BY massif. DuckDB promettait du spill automatique. Ce qu'on a eu : 20 minutes de requête versus 8 secondes sur notre cluster Presto. Le spill sur disque SSD/HDD est fondamentalement limité par les IOs physiques. DuckDB n'a pas de vrai optimiseur de coûts pour les plans avec spill, contrairement aux moteurs colonnaires distribués.

Pour la data petite et moyenne (sous 50 Go en RAM disponible), DuckDB gagne. Au-delà, n'attendez pas de miracle.

L'écosystème outillage : moins mature qu'on ne le dit

DuckDB possède des connecteurs SQL (Python, JS, Rust, CLI). Mais si vous travaillez dans un écosystème hétérogène—Airflow, dbt, Kafka, APIs externes—l'intégration demande du travail custom. DuckDB n'existe pas « nativement » en tant que warehouse dans dbt avant la version récente, et même aujourd'hui, le support des incremental models est basique.

Les adapters Airflow pour DuckDB ne gèrent pas bien la fédération multi-bases. Pas de intégration avec les schedulers d'aggrégations, pas de gestion de metadata catalogs comme Glue ou Unity Catalog. Vous bricolez. C'est acceptable pour des projets de 2-3 personnes, catastrophique pour du multi-équipe.

Nous avons perdu deux semaines à wrapper DuckDB pour le rendre compatible avec notre pipeline dbt existant. Deux semaines. Avec Snowflake ou BigQuery, c'était quelques heures.

Quand vraiment utiliser DuckDB

Soyons clairs sur les vrais use-cases : analytique locale (data scientists), ETL légers de fichiers Parquet, prototypage rapide sans infra, outils mono-utilisateur exécutables, exploration de datasets. Là, c'est excellent. Partez de là, pas du rêve de le généraliser à toute votre stack.

Conclusion pratique : DuckDB est un outil formidable dans son écosystème. Mais c'est un outil tactique, pas une base de données universelle. Si votre besoin implique la concurrence, les gros volumes, l'intégration complexe ou la distribution réseau, investissez dans PostgreSQL, ClickHouse ou Presto. Le hype autour de DuckDB dépasse largement sa maturité réelle. Utilisez-le intelligemment—là où il brille—et acceptez ses limites. C'est exactement comme ça qu'on construit des systèmes robustes.