Pandas vs Polars vs Dask, en graphiques live

Je voulais une page qui montre vraiment la différence entre pandas, Polars et Dask, au lieu de simplement affirmer que Polars est « rapide ». Les trois graphiques ci-dessus sont du Chart.js, exécuté côté client, sur un jeu de données fixe que j’ai choisi à la main – pas un modèle standard avec des chiffres de remplissage. Les stats d’écosystème en bubble chart. Un benchmark en bubble chart scriptable, où la couleur est calculée à partir de la valeur plutôt que figée par bibliothèque. Une courbe d’adoption qui se dessine progressivement, de gauche à droite, comme la croissance réelle s’est déroulée année après année.

Trois bibliothèques, un seul métier – les données tabulaires en Python – et trois compromis très différents entre débit, mémoire, et la part de votre code pandas existant qui survit à la bascule. Les chiffres ci-dessous sont arrondis, datés de septembre 2026, et le benchmark est illustratif plutôt qu’une exécution reproduite précisément sur cette page. Je préfère le répéter une fois de trop plutôt que laisser un graphique suggérer une précision qu’il n’a pas.

1. Pourquoi seules trois bibliothèques se partagent les bulles

Les bubble charts et les nuages de points sont la seule forme de graphique où chaque marque peut finir juste à côté de n’importe quelle autre : une palette catégorielle doit donc survivre à chaque paire possible, pas seulement aux voisins dans une légende. En passant cette vérification « toutes paires » sur mon jeu habituel de huit teintes, seules les trois premières couleurs passent, en mode clair comme en mode sombre, pour une lectrice daltonienne. Ce n’est pas une question de goût – c’est la vraie raison pour laquelle le graphique d’écosystème ci-dessus compare exactement pandas, Polars et Dask, plutôt que cinq bibliothèques dans cinq couleurs boueuses. PySpark et Modin ont droit à un paragraphe plus bas plutôt qu’à une bulle.

pandas devance toujours largement en téléchargements, d’un ordre de grandeur – exactement ce qu’on attend d’un standard vieux de quinze ans avec des milliers d’intégrations. Le plus intéressant, c’est à quel point Polars s’est rapproché de Dask en étoiles GitHub, avec environ un dixième des contributeurs : une petite équipe concentrée qui réécrit le moteur de zéro plutôt que d’étendre une API existante peut apparemment dépasser une équipe bien plus grande.

2. Couleur scriptable, pas couleur d’identité

Le graphique de performance exécute un groupby avec agrégation sur un CSV à deux tailles – 2 Go, qui tient confortablement en mémoire, et 20 Go, à la limite d’un laptop classique. Chart.js permet de définir elements.point.radius et backgroundColor comme des fonctions plutôt que des valeurs fixes – c’est exactement ce que montre l’exemple officiel des options scriptables de Chart.js. Je l’ai utilisé ici pour quelque chose de réellement signifiant : la couleur est calculée directement à partir du temps d’exécution en secondes – rapide, modéré, lent – sans être figée par bibliothèque, si bien que le même vert peut appartenir à Polars à 2 Go ou à Dask à 20 Go. Le rayon des bulles vient de la RAM maximale, sur une échelle en racine carrée, pour que ce soit l’aire, pas le rayon brut, qui suive à peu près linéairement la mémoire.

À 2 Go, Dask perd même face à pandas classique – construire un graphe de tâches a un coût qui ne se rentabilise que lorsqu’il y a assez de travail à répartir. À 20 Go, le tableau s’inverse : pandas mono-thread, qui copie les données en mémoire, se dégrade le plus ; Polars, sur Rust avec SIMD et exécution en streaming, reste dans la zone « modérée » ; Dask, en découpant le fichier en morceaux, garde la mémoire sous contrôle et referme la majeure partie de l’écart de temps avec Polars.

3. Lignes progressives, et ce que je choisirais vraiment

Le graphique de croissance suit les téléchargements PyPI hebdomadaires estimés de 2019 à 2026 pour les mêmes trois bibliothèques, et s’anime comme l’exemple progressive-line de Chart.js : chaque point reçoit son propre délai selon son index, si bien que la ligne se dessine elle-même de gauche à droite au lieu de simplement apparaître en fondu. C’est un écho délibéré du sujet, pas une décoration – l’adoption réelle s’est elle aussi déroulée année après année. pandas se stabilise, ce qui ressemble à un standard mature de quinze ans, pas à une bibliothèque qui recule. Polars, sorti en 2020, montre la courbe classique du démarrage tardif : à peine visible au début, puis une inflexion nette une fois que des gens en dehors de la bulle des passionnés de Rust ont commencé à écrire sur sa vitesse.

Alors, que choisirais-je vraiment ? pandas quand l’écosystème et la mémoire musculaire de l’équipe comptent plus que les secondes brutes. Polars pour un nouveau pipeline sur une seule machine puissante, où mémoire et CPU coûtent de l’argent réel. Dask quand les données ne tiennent plus du tout sur une seule machine et qu’on préfère garder du code en forme pandas plutôt que le réécrire en PySpark. PySpark et Modin se situent encore un cran plus loin – PySpark une fois fermement en territoire cluster ou quand Spark fait déjà tourner l’infrastructure, Modin quand l’objectif honnête est une accélération parallèle avec un changement d’import d’une ligne et aucune envie de réécriture.

• pandas – des données jusqu’à quelques Go, un écosystème maximal, une équipe qui connaît déjà l’API par cœur.
• Polars – une seule machine puissante, un pipeline neuf sans code legacy à traîner, mémoire et CPU qui coûtent vraiment de l’argent.
• Dask – des données qui ne tiennent plus sur une seule machine, une API en forme de pandas qu’on ne veut pas abandonner, un cluster qui existe ou qui arrive.
• PySpark ou Modin – un cran plus loin : PySpark une fois fermement en territoire cluster, Modin pour un changement d’import d’une ligne quand une réécriture est exclue.

À propos des chiffres

Les étoiles GitHub et les téléchargements hebdomadaires PyPI sont des estimations arrondies à septembre 2026, tirées de trackers publics comme pepy.tech et des dépôts de chaque projet. Les chiffres du benchmark reproduisent la forme typique des comparaisons groupby publiques plutôt qu’une exécution que j’aurais faite précisément pour cette page – les secondes réelles dépendent du matériel, des versions et de la forme de vos données. Les trois graphiques reposent sur Chart.js : un bubble chart, un bubble chart scriptable et une animation progressive-line, les trois mêmes schémas d’exemple que Chart.js fournit dans sa propre documentation.