Pourquoi DuckDB est-il si rapide ? Stockage en colonnes, exécution vectorisée et conception d'un moteur analytique moderne

DuckDB est devenu, ces trois dernières années, un outil que toute personne faisant de l'analyse de données avec Python a croisé directement ou indirectement. L'intégration sans copie avec Pandas, Polars et PyArrow a rendu l'exécution de SQL sur des jeux de données de millions de lignes triviale. Le nouvel article technique mis en avant sur Hacker News examine de près les trois choix de conception qui rendent le moteur si rapide.

Première décision : le stockage en colonnes. Les bases relationnelles classiques (PostgreSQL, MySQL) gardent une ligne dans un même bloc disque. Les requêtes analytiques n'exigent en général que la lecture d'une ou deux colonnes. DuckDB stocke toutes les données colonne par colonne, ce qui permet à une requête analytique de ne pas lire les colonnes inutiles.

Deuxième décision : l'exécution vectorisée. Les moteurs classiques traitent la requête ligne par ligne ; une boucle for s'exécute pour chaque ligne. DuckDB traite des lots de 2 048 lignes — un vecteur. Cela s'aligne directement sur les instructions SIMD des processeurs modernes ; moyennes, sommes et comparaisons s'exécutent 4 à 16 fois plus vite.

Troisième décision : l'intégration sans copie. Lorsqu'il travaille avec des structures de données existantes comme Pandas ou PyArrow, DuckDB ne crée pas de copie ; il pointe directement vers la zone mémoire. Pour une base classique, il faudrait normalement écrire le jeu de données sur disque en CSV ou Parquet, puis le relire. DuckDB saute cette étape et lit directement la mémoire Python.

L'addition de ces trois décisions fait que, pour une requête analytique type, DuckDB tourne de 5 à 50 fois plus vite que PostgreSQL et, en général, de 10 à 100 fois plus vite que Pandas. Les benchmarks partagés dans le fil Hacker News indiquent qu'à l'échelle de 100 millions de lignes, DuckDB exécute une requête de regroupement type en environ un dixième du temps de PostgreSQL.

Une autre caractéristique architecturale notable est que la sortie n'est pas optimisée pour l'écriture sur disque. DuckDB repose sur un modèle qui produit le résultat de la requête rapidement en mémoire et le consomme surtout côté Python. C'est inadapté pour des charges OLTP, mais un atout pour l'analytique.

Le projet a poussé sur des racines académiques open source. Il a commencé comme une réflexion au sein du groupe base de données du CWI aux Pays-Bas, a été ouvert au public en 2019, et figure en 2026 dans les piles d'analyse de données d'entreprises comme Goldman Sachs, Stripe, JP Morgan et Klaviyo.

La vitesse de DuckDB ne vient pas du seul stockage en colonnes ni de la seule exécution vectorisée ; ces techniques sont connues. Ce qui fait la différence est l'application conjointe des trois décisions et l'intégration profonde avec l'écosystème de données Python moderne. DuckDB partage un univers de conception avec Apache Arrow et Polars, qui utilisent les mêmes techniques.

Côté licence, DuckDB est diffusé sous licence MIT, ce qui lève un obstacle à l'adoption en entreprise. Pour remplacer un projet de base de données d'entreprise que Cloudera a arrêté l'an dernier, beaucoup d'organisations adoptent DuckDB et l'embarquent directement dans leurs outils internes de visualisation de données.

Message d'ensemble : DuckDB est devenu un nouveau réglage par défaut pour les charges analytiques petites et moyennes. Pouvoir traiter des milliards de lignes directement dans un script Python, sans « serveur de base de données », est probablement l'avancée analytique la plus pratique des dernières années. Le post de Hacker News rappelle que la vitesse tient non à une formule unique, mais à l'effet composite de trois décisions de conception.