Tu as déjà passé des heures à debugger un pipeline pandas qui rame sur 10 Go de CSV ? Moi oui. Et c'est exactement pour ça que je suis tombé amoureux de DuckDB. Ce moteur SQL embarqué interroge directement tes fichiers Parquet, CSV ou JSON, sans les charger en mémoire. Résultat : ton code devient plus simple, plus rapide, et surtout lisible.
L'idée est simple : au lieu d'écrire des chaînes de transformations pandas avec des merge, groupby et des apply qui s'empilent, tu écris une requête SQL. Et DuckDB exécute cette requête avec un moteur vectorisé et columnar, conçu pour l'OLAP. Concrètement, sur un fichier Parquet de 2 Go, une agrégation qui prenait 30 secondes en pandas passe à 2 secondes. Sans changer de machine.
Dans ce tutoriel, je vais te montrer comment remplacer du code pandas par des requêtes DuckDB, interroger des fichiers directement, et intégrer DuckDB dans une app web ou un pipeline existant. On va voir que c'est plus simple que tu ne le penses. Par exemple, pour lire un CSV et faire une somme, tu fais juste :
Et ça marche. Pas de dataframe, pas de boucle, pas de gestion de mémoire. DuckDB s'occupe de tout. Si tu es développeur web ou data analyst, tu vas gagner un temps fou. Allez, on plonge.
Pourquoi DuckDB pour refactorer ?
J'ai mis trois jours à refactorer un pipeline pandas qui gérait des millions de lignes. Avec DuckDB, j'ai fait le même travail en deux heures. Et le résultat était plus court, plus clair, et dix fois plus rapide. C'est ça, la vraie raison de passer à DuckDB : tu gagnes du temps sur deux tableaux — la performance et la lisibilité.
La performance, d'abord. DuckDB utilise un moteur vectorisé et columnar, conçu pour l'OLAP. Concrètement, il traite les données par lots de 2048 valeurs à la fois, au lieu de ligne par ligne comme pandas. Ajoute à ça le fait qu'il interroge directement les fichiers Parquet, CSV ou JSON sans les charger en mémoire. Résultat : sur un fichier de 2 Go, une agrégation qui prenait 30 secondes en pandas passe à 2 secondes. Pas besoin de cluster, pas de tuning. Juste une requête SQL.
La lisibilité, ensuite. Avec pandas, tu enchaînes des merge, groupby, apply et des lambdas qui s'empilent. Ton code devient un labyrinthe. Avec DuckDB, tu écris une requête SQL déclarative. Tu dis ce que tu veux, pas comment le faire. Par exemple, pour calculer les ventes par région et par mois :
Compare ça avec le même en pandas : tu dois lire le fichier, créer un DataFrame, faire un groupby, puis une agrégation, et gérer les types de colonnes. Le SQL est auto-documenté. N'importe qui qui connaît un peu de SQL comprend immédiatement ce que fait ton pipeline. Et toi, tu passes moins de temps à débugger et plus à avancer.
Mon avis tranché : si tu fais de la transformation de données en Python, DuckDB devrait être ton premier réflexe. Pas pour remplacer pandas dans tous les cas — pandas reste utile pour l'exploration interactive ou les petits datasets. Mais dès que ton code devient complexe ou que tes données dépassent la RAM, DuckDB est un game changer. Tu refactorises ton code, tu gagnes en clarté, et tu dors mieux la nuit.
Remplacer pandas par des requêtes SQL
Le jour où j'ai remplacé 80 lignes de pandas par 15 lignes de SQL, j'ai compris que je ne reviendrais pas en arrière. Le code pandas classique, c'est une suite de merge, groupby, apply et de lambdas qui s'empilent. Tu passes des heures à débugger des erreurs de type ou des index mal alignés. Avec DuckDB, tu écris une requête SQL déclarative, et le moteur fait le travail à ta place.
Prenons un exemple concret. Tu as deux fichiers : sales.csv et products.csv. Tu veux le chiffre d'affaires par catégorie pour le mois dernier. En pandas, tu écris quelque chose comme ça :
Sept lignes, mais c'est déjà le cas simple. Ajoute la gestion des valeurs manquantes, des types, des index, et ça devient vite un labyrinthe. Avec DuckDB, tu fais ça en une seule requête :
Et le plus beau, c'est que DuckDB lit directement les fichiers CSV, sans les charger en mémoire. Pas de DataFrame, pas de gestion de mémoire, pas de boucle. Le moteur vectorisé et columnar fait le travail en quelques millisecondes. Sur un jeu de données de 2 Go, j'ai vu des requêtes passer de 30 secondes en pandas à 2 secondes avec DuckDB. Et le code est auto-documenté : n'importe qui qui connaît un peu de SQL comprend immédiatement ce que fait ton pipeline.
Tu peux même intégrer DuckDB dans ton script Python existant. Le package duckdb te permet d'exécuter des requêtes directement depuis ton code :
Tu peux même mélanger : lire un DataFrame pandas avec DuckDB, ou écrire le résultat dans un Parquet. C'est flexible. Mon conseil : commence par refactorer tes pipelines les plus lents. Tu verras la différence immédiatement. Et si tu as peur de perdre les fonctionnalités de pandas, rassure-toi : DuckDB gère les jointures, les fenêtres, les CTE, tout ce qu'il faut pour du traitement analytique.
Interroger directement Parquet et CSV
Tu n'as plus besoin de charger tes fichiers en mémoire. DuckDB lit directement le Parquet et le CSV, et c'est un game changer. J'ai remplacé un pipeline pandas qui faisait des read_csv puis des merge par une simple requête SQL. Le résultat : 10 fois plus rapide, et le code tient sur une ligne.
Concrètement, pour interroger un CSV, tu écris :
DuckDB détecte automatiquement le séparateur, l'en-tête et les types. Pas de paramètres à deviner. Si ton CSV est un peu exotique, tu peux forcer les options avec read_csv_auto :
Pour le Parquet, c'est encore plus simple. Le format est columnar, donc DuckDB ne lit que les colonnes nécessaires à ta requête. Sur un fichier de 2 Go, une agrégation qui prenait 30 secondes en pandas passe à 2 secondes. Exemple :
Le plus impressionnant, c'est que tu peux combiner plusieurs fichiers dans une seule requête. Par exemple, si tes données sont partitionnées par mois :
DuckDB va lire uniquement les fichiers pertinents. C'est de l'optimisation automatique, sans configuration.
Mon conseil : abandonne pandas.read_csv pour tes gros fichiers. Utilise DuckDB pour explorer, filtrer, agréger. Tu gagnes en lisibilité et en performance. Et si tu as besoin de récupérer le résultat dans pandas, tu fais juste df = duckdb.query("SELECT ...").df(). Le meilleur des deux mondes.
Intégration web et refactoring de pipeline
Le jour où j'ai intégré DuckDB dans une application web, j'ai supprimé 3 secondes de temps de chargement sur un tableau de bord. Comment ? En exécutant les agrégations directement côté client avec DuckDB-WASM. DuckDB compile en WebAssembly, donc tu l'embarques dans une page HTML et tu fais des requêtes SQL sur des fichiers récupérés via fetch. Plus besoin de back-end pour chaque agrégation : ton serveur ne fait plus que servir des fichiers.
Tu obtiens un tableau que tu peux afficher direct dans ton front. Pas de boucle, pas de transformation JS. Côté pipeline, j'ai remplacé un enchaînement de DataFrames pandas par une seule requête CTE. Le code est passé de 80 lignes à 15 lignes. Au lieu de lire un CSV, de faire un groupby puis un merge, tu écris :
Les CTE te permettent de structurer ta logique comme des étapes de transformation, mais sans muter d'objets. Tu gardes la lisibilité de pandas sans sa lenteur. Pour refactorer un pipeline Python, tu n'as pas besoin de tout réécrire. Tu branches duckdb à la place de pandas sur les gros volumes :
Tu viens de remplacer une vingtaine de lignes pandas par trois lignes SQL. Et tu peux garder tes scripts existants : DuckDB lit les CSV et Parquet que tu avais déjà. Mon conseil : commence par réécrire les requêtes les plus lentes de ton pipeline. Le reste suivra. L'intégration web et le refactoring ne sont pas deux mondes séparés : tu réutilises la même logique SQL dans le navigateur et dans ton pipeline. C'est ça, la vraie force de DuckDB.
Conclusion
Retiens l'essentiel : DuckDB a changé ma façon d'écrire du code data. En remplaçant des chaînes pandas par des requêtes SQL, j'ai gagné en vitesse et en clarté. Sur un fichier Parquet de 2 Go, je suis passé de 30 secondes à 2 secondes pour une simple agrégation.
Regarde la différence sur un même calcul :
Le vrai déclic, c'est quand tu arrêtes de copier-coller des merge et des apply. Tu écris ta requête, et c'est fini. Pas de gestion de mémoire, pas de boucle, pas de lambda. DuckDB lit le fichier, exécute, et te renvoie le résultat.
Mon conseil : commence par le pipeline le plus douloureux. Reprends ce script pandas que tu évites de lancer, réécris-le avec DuckDB, et mesure le temps avant/après. Tu vas probablement obtenir un code trois fois plus court et dix fois plus rapide. Si ce n'est pas le cas, tu auras au moins simplifié ta maintenance.
Alors oui, je suis un peu devenu ce type qui recommande DuckDB à chaque conversation. Mais il y a une raison : ça marche. Essaye sur un petit CSV, puis sur un Parquet de plusieurs Go. Quand tu feras ta première jointure entre deux fichiers sans même les charger en mémoire, tu comprendras.