Der Oktober 2026 war ein voller Monat für Daten-Engines. DuckDB 2.0 erschien am 21. Oktober als Version mit Langzeit-Support, Polars 2.1 am 25. Oktober und Apache Spark 4.3 am 30. Oktober. Alle drei sind kostenlos und Open Source, lesen Parquet und Apache Iceberg und sprechen inzwischen SQL. Welche also nehmen? Wir haben die neuen Versionen installiert, dieselben Abfragen auf denselben 20 Millionen Zeilen ausgeführt und festgehalten, was wir gelernt haben.
Drei Engines, drei Konzepte
DuckDB 2.0
SQL-Datenbank in einer Datei- Lizenz
- MIT
- Stil
- zuerst SQL, mit Clients für Python, R, Java und Node
- Läuft
- in Ihrem Prozess, jetzt auch als kleiner Server (Quack)
- Hervorragendes SQL: ASOF- und NEAREST-Joins, Trigger, MERGE, ein schneller VARIANT-Typ für JSON
- Liest Parquet, CSV, JSON, Iceberg, Delta und DuckLake, lokal oder aus dem Cloud-Speicher
- Langzeit-Support mindestens bis Oktober 2027
- Nur eine Maschine; sehr große Shuffles brauchen weiterhin Sorgfalt
Ideal für SQL-Nutzer, Notebooks, Dashboard-Backends und lokale Analysen.
Polars 2.1
DataFrame-Bibliothek- Lizenz
- MIT
- Stil
- Python-Ausdrücke, dazu eine wachsende SQL-Schnittstelle
- Läuft
- in Ihrem Prozess, standardmäßig mit Streaming-Engine
- Schnell, streng und vorhersehbar: Typen und Fehler sind explizit
- Group-bys können auf die Festplatte auslagern, wenn der Speicher knapp wird
- Schreibt und verwaltet Iceberg-Tabellen
- Braucht Python 3.11 oder neuer; einige neue APIs sind instabil
Ideal für Python-Entwickler, die pandas ersetzen.
Spark 4.3
Verteilte Engine- Lizenz
- Apache 2.0
- Stil
- SQL, PySpark-DataFrames, Scala und Java
- Läuft
- auf Clustern, über Databricks, Fabric, EMR, Dataproc oder eigene
- Skaliert über viele Maschinen, bis zu Hunderten Terabyte
- Echtzeit-Streaming mit Zustand, jetzt um 150 ms P99
- Der Standard auf Databricks und Microsoft Fabric
- Sekunden an Startzeit und Fixkosten pro Abfrage bei kleinen Daten
Ideal, wenn eine Maschine nicht reicht.
Der Benchmark
Wir haben eine Parquet-Datei mit 20 Millionen Verkaufszeilen (236 MB, vier Spalten) und eine kleine Tabelle mit 1.000 Filialen erzeugt und dann in jeder Engine zwei Abfragen ausgeführt, wobei die Parquet-Dateien jedes Mal neu gelesen wurden. Angegeben ist der schnellste von drei Läufen. Die Maschine war eine bescheidene Cloud-VM mit 2 CPU-Kernen und 7 GB Speicher; die absoluten Zahlen werden bei Ihnen anders sein, entscheidend ist die Reihenfolge.
Schnellster von 3 Läufen. DuckDB 2.0.0, Polars 2.1.0, pandas 3.1.0, PySpark 4.3.0 im lokalen Modus mit 2 Kernen. Jeder Lauf liest die Parquet-Datei.
Gleiche Maschine und Methode. Der Join fügt 20 Millionen Verkaufszeilen 1.000 Filialzeilen hinzu.
Das Bild ist eindeutig. Auf einer Maschine spielen DuckDB und Polars in einer eigenen Liga, und welche schneller ist, hängt von der Abfrage ab: Polars lag bei der Aggregation mit vielen Gruppen knapp vorn, DuckDB war beim Join mehr als doppelt so schnell. pandas, das zuerst alles in den Speicher lädt, war 2,5- bis 8-mal langsamer. Spark war hier am langsamsten, was zu erwarten ist: Es ist dafür gebaut, Arbeit auf viele Maschinen zu verteilen, und auf zwei Kernen misst man vor allem seinen Koordinationsaufwand.
Kleine Abfragen: wo der Fixaufwand sichtbar wird
Die neue Einstellung Project Feather in Spark 4.3 senkte die Mini-Abfrage von 85 auf 53 ms, weil der Shuffle entfällt, eine echte Verbesserung zum Testen von Code an Stichproben. DuckDB und Polars antworten aber in etwa einer Millisekunde, und der Start einer lokalen Spark-Session dauerte 5,3 Sekunden, bevor überhaupt eine Abfrage lief. Wenn Ihre Daten auf einen Laptop passen, summiert sich dieser Unterschied den ganzen Tag.
Mehr als Geschwindigkeit
| DuckDB 2.0 | Polars 2.1 | Spark 4.3 | |
|---|---|---|---|
| Hauptschnittstelle | SQL | Python-Ausdrücke | SQL und PySpark |
| Größer als der Speicher | Ja, lagert auf Festplatte aus | Ja, Streaming-Engine und auslagernde Group-bys | Ja, über einen Cluster |
| Größer als eine Maschine | Nein | Nein (Open Source) | Ja |
| Streaming | Nein | Stapelweises Streaming großer Dateien | Ja, auch in Echtzeit mit Zustand |
| Offene Tabellenformate | Iceberg, Delta, DuckLake | Iceberg lesen und schreiben, Delta | Iceberg und Delta, die Referenz-Engine |
| Gemeinsamer Zugriff | Neuer Servermodus Quack | Nur im Prozess | Spark Connect, Mehrbenutzer-Cluster |
| KI-Coding-Agenten | Agentenmodus in der CLI spart Ausgabe-Tokens | Klare Fehler, strenge Typen | Feather beschleunigt die Testen-und-Korrigieren-Schleife |
So entscheiden Sie
- 1
Schätzen Sie Ihre größte Tabelle
Unter etwa 100 GB Parquet reicht meist eine Maschine mit DuckDB oder Polars. Im Terabyte-Bereich oder bei schnellem Wachstum planen Sie Spark oder ein Cloud-Warehouse ein.
- 2
Wählen Sie nach der Sprache des Teams
SQL-Nutzer sind in DuckDB nach einer Stunde produktiv. Python-Entwickler bevorzugen die Ausdrücke von Polars.
- 3
Prüfen Sie, wo der Job läuft
Nutzt Ihr Unternehmen Databricks oder Microsoft Fabric, ist Spark bereits vorhanden und verwaltet, und kleine Jobs können trotzdem DuckDB oder Polars in denselben Notebooks nutzen.
- 4
Echtzeit nötig? Nehmen Sie Spark
Weder DuckDB noch Polars verarbeiten Ereignisströme mit Zustand. Spark 4.3 schafft das jetzt mit etwa einer Zehntelsekunde Latenz.
- 5
Halten Sie Daten in offenen Formaten
Speichern Sie Tabellen als Parquet oder Iceberg, damit Sie die Engine später ohne Datenmigration wechseln können.
Testen Sie Ihr Wissen
1/3Welche Engine war in unserem Join-und-Group-by-Test auf 20 Millionen Zeilen am schnellsten?
DuckDB brauchte 0,20 Sekunden, Polars 0,48, pandas 1,62 und Spark 1,83.
2/3Wann ist Spark die richtige Wahl statt DuckDB oder Polars?
Sparks Stärke sind Skalierung und Streaming; bei kleinen Daten überwiegt der Fixaufwand.
3/3Was macht Project Feather in Spark 4.3?
In unserem Test senkte es eine Mini-Abfrage von 85 auf 53 ms.
Sie haben 0 von 3 richtig.
Weiterlesen: DuckDB 2.0, Polars 2.1, Spark 4.3, der Polars-Spickzettel und wie man eine Datenbank auswählt.
Quellen: Ankündigung von DuckDB 2.0.0 (21. Oktober 2026), Release Notes zu Polars 2.1 (25. Oktober 2026) und Apache Spark 4.3.0 (30. Oktober 2026). Die Benchmarks sind unsere eigenen, ausgeführt am 9. November 2026 auf einer Cloud-VM mit 2 Kernen und 7 GB mit synthetischen Daten; sie sind Richtwerte und ersetzen keinen Test mit Ihrer eigenen Last.
Alessandro Ecclesie AgazziGeschrieben von Alessandro Ecclesie Agazzi, Analytics Engineer in London. Aktualisiert am 9 November 2026. Über mich