Pandas vs Polars vs Dask, live im Chart

Ich wollte eine Seite, die den Unterschied zwischen pandas, Polars und Dask wirklich zeigt, statt nur zu behaupten, Polars sei „schnell“. Die drei Diagramme oben sind Chart.js, das clientseitig läuft, mit einem von Hand gewählten festen Datensatz – keine Vorlage mit Platzhalterzahlen. Ökosystem-Kennzahlen als Bubble-Chart. Ein Benchmark als scriptable Bubble-Chart, dessen Farbe aus dem Wert berechnet wird, statt an eine Bibliothek gebunden zu sein. Eine Adoptionskurve, die sich progressiv von links nach rechts selbst zeichnet – genauso, wie sich das reale Wachstum Jahr für Jahr entfaltet hat.

Drei Bibliotheken, eine Aufgabe – tabellarische Daten in Python – und drei sehr unterschiedliche Kompromisse zwischen Durchsatz, Speicher und der Frage, wie viel Ihres bestehenden pandas-Codes den Wechsel übersteht. Die Zahlen unten sind gerundet, Stand September 2026, und der Benchmark ist illustrativ, kein Lauf, den ich genau auf dieser Seite reproduziert habe. Lieber sage ich das einmal zu oft, als einem Diagramm mehr Präzision zu unterstellen, als es hat.

1. Warum sich nur drei Bibliotheken die Bubbles teilen

Bubble- und Scatter-Charts sind die eine Diagrammform, bei der jede Markierung direkt neben jeder anderen landen kann – eine kategoriale Farbpalette muss also jedes mögliche Paar überstehen, nicht nur Nachbarn in einer Legende. Lässt man diese All-Pairs-Prüfung über mein übliches Set aus acht Farbtönen laufen, bestehen sie nur die ersten drei Farben, in Hell- und Dunkelmodus, für eine farbenblinde Leserin. Das ist keine Geschmacksfrage – es ist der eigentliche Grund, warum das Ökosystem-Diagramm oben genau pandas, Polars und Dask vergleicht statt fünf Bibliotheken in fünf trüben Farben. PySpark und Modin bekommen weiter unten einen Absatz statt einer Bubble.

pandas gewinnt bei den Downloads immer noch um eine Größenordnung – genau das, was man von einem 15 Jahre alten Standard mit Tausenden Integrationen erwarten würde. Interessanter ist, wie nah Polars bei den GitHub-Stars an Dask herangekommen ist, mit etwa einem Zehntel der Contributor-Zahl – ein kleines, fokussiertes Team, das die Engine von Grund auf neu schreibt statt eine bestehende API zu erweitern, kann offenbar ein deutlich größeres Team überholen.

2. Scriptable Farbe statt Identitätsfarbe

Das Performance-Diagramm führt ein Groupby-mit-Aggregation auf einer CSV in zwei Größen aus – 2 GB, die bequem in den Speicher passen, und 20 GB, am Rand eines typischen Laptops. Mit Chart.js kann man elements.point.radius und backgroundColor als Funktionen statt als feste Werte setzen – genau das zeigt Chart.js’ eigenes Scriptable-Options-Beispiel. Ich habe es hier für etwas mit echter Bedeutung eingesetzt: Die Farbe wird direkt aus der Laufzeit in Sekunden berechnet – schnell, mäßig, langsam –, nicht an eine Bibliothek gebunden, sodass dasselbe Grün zu Polars bei 2 GB oder zu Dask bei 20 GB gehören kann. Der Bubble-Radius kommt aus dem Spitzen-RAM, auf einer Quadratwurzel-Skala, damit die Fläche und nicht der rohe Radius ungefähr linear zum Speicher passt.

Bei 2 GB verliert Dask sogar gegen normales pandas – der Aufbau eines Task-Graphen hat einen Overhead, der sich erst lohnt, wenn genug Arbeit vorhanden ist, um sie zu verteilen. Bei 20 GB dreht sich das Bild: Single-threaded pandas, das Daten im Speicher kopiert, degradiert am stärksten; Polars, auf Rust mit SIMD und Streaming-Ausführung, bleibt im „moderaten“ Bereich; Dask, das die Datei in Chunks aufteilt, hält den Speicher im Griff und schließt den Großteil des Zeitabstands zu Polars.

3. Progressive Linien – und wonach ich tatsächlich greifen würde

Das Wachstumsdiagramm verfolgt geschätzte wöchentliche PyPI-Downloads von 2019 bis 2026 für dieselben drei Bibliotheken und animiert genau wie Chart.js’ eigenes progressive-line-Beispiel: Jeder Punkt bekommt eine eigene Verzögerung basierend auf seinem Index, sodass sich die Linie von links nach rechts selbst zeichnet, statt nur einzublenden. Das ist ein bewusstes Echo des Themas, keine Dekoration – auch das reale Wachstum entfaltete sich Jahr für Jahr. pandas flacht ab, was bei einem reifen, 15 Jahre alten Standard so aussieht, nicht bei einer Bibliothek, die an Boden verliert. Polars, 2020 veröffentlicht, zeigt die lehrbuchhafte Spätstart-Kurve: anfangs kaum sichtbar, dann ein scharfer Knick, sobald Leute außerhalb der Rust-Enthusiasten-Blase über die Geschwindigkeit zu schreiben begannen.

Wonach würde ich also tatsächlich greifen? pandas, wenn Ökosystem und Muscle Memory des Teams mehr zählen als rohe Sekunden. Polars für eine neue Pipeline auf einer starken Maschine, wo Speicher und CPU echtes Geld kosten. Dask, wenn die Daten überhaupt nicht mehr auf eine Maschine passen und man lieber pandas-förmigen Code behält, statt ihn in PySpark neu zu schreiben. PySpark und Modin liegen noch einen Schritt weiter draußen – PySpark, sobald man fest im Cluster-Terrain ist oder Spark bereits die Infrastruktur betreibt, Modin, wenn das ehrliche Ziel ein paralleler Speedup mit einer einzeiligen Import-Änderung und null Lust auf ein Rewrite ist.

• pandas – Daten bis zu ein paar GB, maximales Ökosystem, ein Team, das die API bereits im Schlaf beherrscht.
• Polars – eine starke einzelne Maschine, eine frische Pipeline ohne Legacy-Code im Schlepptau, Speicher und CPU, die wirklich Geld kosten.
• Dask – Daten, die nicht mehr auf eine Maschine passen, eine pandas-förmige API, die man nicht aufgeben will, ein Cluster, der existiert oder kommt.
• PySpark oder Modin – einen Schritt weiter: PySpark, sobald man fest im Cluster-Terrain ist, Modin für einen einzeiligen Import-Tausch, wenn ein Rewrite nicht infrage kommt.

Zu den Zahlen

GitHub-Sterne und wöchentliche PyPI-Downloads sind gerundete Schätzungen, Stand September 2026, aus öffentlichen Trackern wie pepy.tech und den Repositories der Projekte selbst. Die Benchmark-Zahlen bilden die typische Form öffentlicher Groupby-Vergleiche nach, keinen Lauf, den ich für genau diese Seite ausgeführt habe – reale Sekunden hängen von Hardware, Versionen und der Form Ihrer Daten ab. Alle drei Diagramme basieren auf Chart.js: eine Bubble-Chart, eine scriptable Bubble-Chart und eine progressive-line-Animation – dieselben drei Beispielmuster, die Chart.js in der eigenen Dokumentation mitliefert.