Im Sommer 2025 saß Anja, Lead Data Engineer bei einem Kölner Mobilitätsanbieter, vor einer ungewöhnlichen Frage. Ihr Team bekam zu hören, der bestehende Spark-Cluster sei zu teuer geworden. Drei Knoten in Frankfurt, monatlich rund 4.500 EUR Infrastrukturkosten plus Wartungsaufwand, für eine Pipeline, die einmal pro Nacht 80 Gigabyte Buchungsdaten verarbeitete und tagsüber Standby lief. Eine externe Beraterin schlug vor, das Ganze auf eine einzelne, gut ausgestattete Maschine mit Polars umzubauen. Anja war skeptisch. Spark war ihr Standard-Werkzeug, sie kannte das Programmiermodell, sie hatte das Tooling im Griff. Polars hatte sie zwar in einem Notebook ausprobiert, aber für Produktion? Sechs Wochen später lief die neue Pipeline auf einer Maschine mit 64 Kernen und 256 GB RAM, kostete unter 600 EUR im Monat und brauchte für denselben Job 18 statt vorher 47 Minuten.
Diese Geschichte beschreibt eine Verschiebung, die viele Datenteams 2026 beschäftigt. Lange Zeit war "Big Data" gleichbedeutend mit verteilter Verarbeitung. Wer Daten analysieren wollte, dachte in Cluster-Knoten und JVM-Heaps. Inzwischen sind die Hardware-Sprünge der vergangenen Jahre so groß, dass eine einzelne Maschine deutlich mehr leistet, als die meisten Teams glauben. Gleichzeitig hat die Engine-Landschaft drei klar unterscheidbare Antworten hervorgebracht. Apache Spark für verteilte Workloads, Polars für sehr leistungsstarke Single-Machine-Verarbeitung und DuckDB für eingebettete analytische Abfragen. Wer 2026 eine Engine wählt, sollte verstehen, wann welche dieser Antworten passt.
Wann lohnt sich verteiltes Rechnen wirklich?
Bevor wir uns die einzelnen Engines anschauen, ist eine grundsätzliche Vorfrage zu klären. Verteilte Verarbeitung lohnt sich, wenn ein Datensatz nicht mehr auf eine Maschine passt oder wenn der Rechenaufwand pro Datensatz so hoch ist, dass selbst eine sehr starke Maschine zu lange braucht. Beide Bedingungen sind in der Praxis seltener erfüllt, als die Branche oft suggeriert. Eine moderne Bare-Metal-Maschine mit hochkernigen AMD-EPYC- oder Intel-Xeon-Prozessoren und 1 bis 1,5 TB RAM kostet im Eigenbetrieb (etwa über Hetzners DX-Serie) monatlich im niedrigen vierstelligen Eurobereich, in der Cloud bei AWS, Azure oder GCP eher zwischen 3.000 und 5.000 EUR. Hetzner hat zum 1. April 2026 die Preise für seine Dedicated-Server-Linie angehoben (etwa der DX293 von 305,60 auf 355,60 EUR), bleibt aber im Vergleich zu Hyperscalern immer noch deutlich günstiger [9]. Auf so einer Maschine laufen analytische Workloads bis in den niedrigen Terabyte-Bereich problemlos.
Die Schwelle, ab der sich der Sprung in den Cluster wirklich rechnet, ist meines Erachtens deutlich höher angesiedelt als der historische Reflex glauben macht. Wer mit Datensätzen unter 500 Gigabyte pro Job hantiert, sollte sich zweimal fragen, ob er den operativen Mehraufwand eines Spark-Clusters wirklich braucht. Hinzu kommt, dass Cluster nicht magisch schneller werden. Sie verteilen Arbeit auf viele Knoten und müssen dafür Daten zwischen ihnen verschieben. Bei kleinen Datenmengen kostet diese Koordination häufig mehr Zeit, als sie spart. Anjas Pipeline aus der Eingangsgeschichte ist genau dafür ein Lehrbuchbeispiel.
Es gibt aber Szenarien, in denen verteilt gerechnet werden muss. Petabyte-große Datensätze, sehr viele parallele Konsumenten, sehr lange laufende Jobs mit hohem Memory-Bedarf, Streaming-Pipelines mit garantiert niedriger Latenz, oder Trainingsläufe für sehr große ML-Modelle. In all diesen Fällen ist Spark oder ein vergleichbares Framework die richtige Wahl. Die Kunst besteht darin, ehrlich zu prüfen, in welche Kategorie das eigene Vorhaben gehört.
Eine kleine Heuristik hilft beim Sortieren. Erstens: Wenn der größte einzelne Datensatz in den Hauptspeicher einer guten Maschine passt (typischerweise 256 GB bis 1.5 TB), ist verteiltes Rechnen selten nötig. Zweitens: Wenn ein Job in unter zwei Stunden auf einer einzelnen Maschine durchläuft, bleibt selbst ein nächtlicher Lauf praktikabel. Drittens: Wenn die Anzahl paralleler Konsumenten unter zehn liegt, reicht eine starke Maschine in den meisten Fällen. Erst wenn zwei dieser drei Bedingungen verletzt sind, lohnt der Sprung in den Cluster.
Was macht Apache Spark im Datenzentrum stark?
Apache Spark ist seit Jahren die etablierte verteilte Verarbeitungs-Engine. Sie ist in Scala geschrieben, läuft auf der Java Virtual Machine und bietet Schnittstellen für Python, SQL, Scala und R. Spark zerlegt eine Berechnung in einen Plan aus Aufgaben, der über viele Knoten eines Clusters parallel ausgeführt werden kann. Aus technischer Sicht ist die Kombination mit S3-kompatiblem Object Storage besonders überzeugend, weil beide Systeme von Haus aus für Parallelität ausgelegt sind. Hunderte Worker können gleichzeitig auf denselben Bucket zugreifen, ohne dass eine Sperrungs- oder Konsistenzschicht zum Engpass wird.
Mit Spark 4 hat das Projekt 2025 einen größeren Schritt gemacht. Spark Connect entkoppelt den Client vom Cluster, was eine ganz andere Art der Nutzung erlaubt [6]. Ein Notebook, eine Webanwendung oder ein lokales Skript spricht über eine schmale gRPC-Schnittstelle mit dem Cluster, ohne dass die ganze JVM-Maschinerie auf der Client-Seite mitlaufen muss. Mit Spark 4.0 gilt Spark Connect als produktionsreif. Im Februar 2026 wurde 4.1.1 als Wartungsrelease veröffentlicht, von 4.2.0 sind bisher drei Preview-Versionen erschienen (Februar, März und 9. April 2026), eine stabile Version ist in den kommenden Monaten zu erwarten [1]. Wer eine produktive Spark-Pipeline aufbaut, sollte heute auf der 4.x-Linie aufsetzen, nicht mehr auf 3.5. Die 4.0er-Linie wird offiziell bis zum 23. November 2026 unterstützt.
Eine Eigenheit, die häufig unterschätzt wird, ist der lokale Modus. Spark lässt sich auf einem einzelnen Rechner starten und nutzt dann mehrere CPU-Kerne der Maschine. Das ist der ideale Einstieg, weil sich derselbe Code später ohne nennenswerte Anpassungen auf einen Cluster heben lässt. Wer mit kleinen Datenmengen anfängt, muss nicht erst eine ganze Infrastruktur aufbauen, um sich mit dem Programmiermodell vertraut zu machen. Sobald die Daten wachsen, übernimmt derselbe Code im Cluster die Arbeit.
Wo liegt der Haken? Spark ist keine leichte Kost. Die Konfiguration eines Clusters mit Yarn, Kubernetes oder Standalone-Modus, die Pflege der Treiber- und Executor-Speicher, das Debugging von Out-of-Memory-Fehlern in der JVM, die Stabilisierung von Shuffles bei sehr großen Joins, all das gehört zum Alltag. Wer Spark produktiv betreibt, sollte mindestens eine Person im Team haben, die diese Themen beherrscht. Allein die Kostenoptimierung eines mittelgroßen Spark-Clusters kann mehrere Personentage pro Quartal verschlingen.
Wer Spark in der DACH-Region produktiv einsetzt, findet zwei verbreitete Pfade. Erstens die Cluster-Variante auf Kubernetes oder einem Hyperscaler-Dienst (AWS EMR oder EMR on EKS, Azure Synapse, Google Dataproc, Databricks). EMR on EKS hat sich nach AWS-eigenen Benchmarks als deutlich günstiger erwiesen als das klassische EMR (bis 61 Prozent Kostenreduktion bei vergleichbarer Performance) [8], und die EMR-7.5-Runtime führt Spark- und Iceberg-Workloads laut AWS rund 3,6-mal schneller aus als die alte 3.5.3-Linie. Google Dataproc startet Cluster in unter 90 Sekunden und rechnet mit 0,01 USD pro vCPU und Stunde Management-Aufschlag oben auf die GCE-VM-Preise. Zweitens das Auslagern an einen Managed Service wie Databricks, der die Clusterverwaltung weitgehend abnimmt. Für reine Spark-Workloads ohne Lakehouse-Anspruch ist EMR oder Dataproc oft die wirtschaftlichste Wahl. Wer ohnehin in einer Lakehouse-Welt lebt, sollte Databricks ernst nehmen, muss aber mit dem entsprechenden Lock-in leben. Für mittelgroße europäische Mittelständler ist die Eigenbetrieb-Variante auf Hetzner-Servern eine ernsthafte Option, vor allem wenn die Cluster-Größe stabil bleibt und Bursting-Anforderungen niedrig sind.
Wie erobert Polars die Single-Machine-Welt zurück?
Polars ist ein deutlich jüngeres Werkzeug, geschrieben in Rust, mit Bindings für Python, R und Node. Es richtet sich an Datenmengen, die noch auf eine einzelne, gut ausgestattete Maschine passen, also typischerweise bis in den niedrigen dreistelligen Gigabyte-Bereich. Aktuelle Version ist Polars 1.40.1 vom 22. April 2026 [2]. In dieser Zone schlägt Polars klassische Werkzeuge wie Pandas in den meisten Benchmarks deutlich, in einigen vCPU-Konfigurationen sogar um den Faktor 30. Es nutzt alle CPU-Kerne effizient aus, hat eine sehr saubere und ausdrucksstarke API für komplexe Aggregationen und liest Parquet-Dateien aus S3 direkt, ohne dass dafür ein Cluster nötig wäre.
Eine wichtige Neuerung der 1.40er-Linie ist die produktionsreife Streaming-Engine. Sie führt Abfragen in Batches aus und kann damit Datenmengen bedienen, die nicht vollständig in den Hauptspeicher passen. In den Polars-eigenen PDS-H-Benchmarks (TPC-H-Variante) zog die Streaming-Engine bei wachsenden Datenvolumen deutlich an der klassischen In-Memory-Engine vorbei [11]. Dazu kommt die Common-Subplan-Elimination in collect_all, die mehrfach genutzte Teilausdrücke nur einmal ausführt. Beide Änderungen schließen genau die Lücke, an der Polars in der Vergangenheit gegen Spark verloren hatte.
Was Polars besonders macht, ist die Kombination aus zwei Eigenschaften. Erstens nutzt das Werkzeug eine Lazy-Evaluation, ähnlich wie Spark. Statt jede Operation sofort auszuführen, baut Polars einen Ausführungsplan auf und optimiert ihn, bevor die Daten überhaupt gelesen werden. Predicate Pushdown, Projection Pushdown und Common-Subexpression-Elimination sind eingebaut. Zweitens ist die API ausdrucksstark, ohne überladen zu sein. Wer Pandas kennt, findet sich in Polars schnell zurecht, profitiert aber von einer konsistenteren Syntax und deutlich besseren Fehlermeldungen [5].
Für viele praktische Aufgaben in mittelgroßen Organisationen ist Polars die pragmatischere Wahl. Spark zahlt mit Komplexität und JVM-Overhead, was sich erst ab einem gewissen Datenvolumen rechnet. Polars liefert auf einem einzigen Server mit ausreichend Hauptspeicher Antwortzeiten, die mit kleineren Spark-Clustern konkurrieren können. In meinen eigenen Vergleichen hat Polars auf einer 64-Kern-Maschine bei Datensätzen bis 200 Gigabyte regelmäßig schneller geliefert als ein Spark-Cluster mit drei Knoten gleicher Größe.
Eine ehrliche Einordnung: Polars ist kein Spark-Ersatz. Wer Streaming, sehr große Joins über Petabyte-Datenbestände oder verteilte Trainingsläufe braucht, kommt um eine Cluster-Engine nicht herum. In TPC-H-ähnlichen Benchmarks bei knapper Hardware (4 oder 8 vCores) lief Polars in einigen Tests in Out-of-Memory-Fehler, während Spark mit Native Execution Engine die Jobs noch durchbrachte. Polars deckt also den Korridor ab, in dem viele Teams operieren, ohne ihn als solchen zu erkennen, hat aber klare Grenzen, sobald die Hardware-Reserven knapp werden. Für solche Fälle baut das Polars-Team mit Polars Cloud zusätzlich eine verteilte Architektur auf, in der LazyFrames an einen Cluster ausgelagert werden können. Stand April 2026 ist das Angebot noch jung, der Open-Source-Kern auf einer Maschine bleibt vorerst der Hauptanwendungsfall.
Anjas Pipeline aus Köln war kein Einzelfall. Die Beraterin, die den Wechsel vorschlug, hatte zuvor bei drei anderen Mittelständlern in Nordrhein-Westfalen ähnliche Migrationen durchgeführt. In jedem Fall lag die Datenmenge unter 300 GB pro Job, in jedem Fall sank der Infrastrukturaufwand um den Faktor fünf bis acht. Solche Erfahrungen verändern die Wahrnehmung dessen, was als Standard gilt. Spark wird nicht falsch, aber die Default-Wahl wird sich in den nächsten Jahren in Richtung Single-Machine-Werkzeuge verschieben, einfach weil die meisten Workloads klein genug sind, um nicht verteilt zu werden.
Warum DuckDB im Notebook und am Endpunkt überzeugt
DuckDB verdient eine eigene Erwähnung, auch wenn es im engeren Sinn weniger eine Engine als eine eingebettete analytische Datenbank ist. Es lässt sich aus Python, R oder Node ansprechen, kennt Parquet als natives Eingabeformat und kann Tabellen direkt aus S3-Buckets abfragen, ohne dass eine eigene Speicherinstanz vorgehalten werden muss. Mit Version 1.5.2 vom 13. April 2026 ist die DuckLake-Erweiterung produktionsreif geworden, mit Geometry-Support, sortierten Tabellen, Bucket-Partitionierung und Iceberg-kompatiblen Deletion-Vectors. Die Iceberg-Erweiterung unterstützt seit Ende 2025 nicht nur das Lesen, sondern auch Inserts, Updates und Deletes auf Iceberg-v2-Tabellen [3][7]. Mit der 1.5.2 ist zusätzlich die Anbindung an Google BigLake über EXTRA_HTTP_HEADERS möglich, was die Liste der erreichbaren Hyperscaler-Kataloge erweitert.
DuckDB hat sich in den letzten zwei Jahren als das Werkzeug erster Wahl etabliert, wenn Analystinnen und Analysten in einem Notebook ad hoc gegen einen Data Lake arbeiten möchten. Der Aufwand, eine Verbindung zu einem Bucket aufzubauen und eine Parquet-Datei abzufragen, ist auf wenige Zeilen Code geschrumpft. Eine Frage wie "Welche Top-10-Kunden hatten in Q1 2026 die höchsten Stornoquoten?" lässt sich gegen Rohdaten in einem S3-Bucket innerhalb von Sekunden beantworten. Genau dafür war DuckDB gedacht.
Eine besonders nützliche Eigenschaft ist der WebAssembly-Client, der seit Ende 2025 produktionsreif ist [4]. Damit lässt sich DuckDB direkt in einer Browser-Anwendung ausführen und kann Iceberg-Datasets aus einem S3-Bucket abfragen, ohne dass eine eigene Server-Infrastruktur nötig wäre. Auf der AWS re:Invent 2025 demonstrierte das DuckDB-Team die Browser-Variante zusammen mit Amazon S3 Tables. Für offene Datenkataloge, interne Tools oder kleine analytische Anwendungen ist das ein Architekturansatz, der vor zwei Jahren so noch nicht denkbar war.
Ein Beispiel macht den Mehrwert konkret. Eine deutsche Behörde stellt Statistiken zum Energieverbrauch öffentlich zur Verfügung. Bisher lief das über eine klassische Webanwendung mit Backend, Datenbank und API. Mit DuckDB-Wasm reicht ein statischer Webserver, der die Parquet-Dateien ausliefert, plus ein paar Kilobyte JavaScript für die Abfragelogik. Die Zugriffe auf das Backend entfallen vollständig, die Auslieferung skaliert über ein klassisches CDN, und die Daten bleiben gleichzeitig vollständig durchsuchbar. Solche Architekturen werden 2026 sukzessive Standard, weil sie Betriebskosten massiv senken.
Ein nüchterner Hinweis gehört dazu. DuckDB ist eingebettet, das heißt: ein Prozess, eine Verbindung. Mehrere parallele Schreibvorgänge auf dieselbe DuckDB-Datei funktionieren nicht zuverlässig. Wer Daten schreiben will, sollte das in einer separaten ETL-Schicht tun und DuckDB ausschließlich für Leseabfragen einsetzen, oder auf DuckLake umsteigen, das genau diese Mehrnutzer-Schreibproblematik adressiert. Bemerkenswert ist außerdem die Memory-Effizienz: DuckDB hält in Benchmarks selbst bei nahezu zwei Terabyte verarbeiteter Daten den Spitzenspeicher unter 2,5 GB, weil der eingebaute Buffer-Manager harte Grenzen erzwingt. Für ressourcenarme Maschinen ist das ein gewichtiges Argument zugunsten von DuckDB gegenüber Polars.
| Engine | Aktuelle Version (April 2026) | Typische Datenmenge | Besonderheit | Sweet Spot |
|---|---|---|---|---|
| Apache Spark | 4.1.1 stable, 4.2.0 in Preview | Mehrere Terabyte bis Petabyte | Verteilte JVM-Engine, Spark Connect, NEE-Runtime, lokaler und Cluster-Modus | Großdaten-ETL, produktive Pipelines |
| Polars | 1.40.1 (22. April 2026) | Bis in den niedrigen dreistelligen Gigabyte-Bereich, mit Streaming-Engine deutlich darüber | Rust, multi-core auf einer Maschine, Lazy Evaluation, neue Streaming-Engine | Mittelgroße Transformationen, Forschung, Notebooks |
| DuckDB | 1.5.2 (13. April 2026) | Bis ungefähr ein Terabyte, sehr speichereffizient | Eingebettete analytische SQL-Datenbank, DuckLake 1.0, WebAssembly-Client | Ad-hoc-Analysen, Notebooks, eingebettete Anwendungen |
Wie sich die drei Engines in einer Datenplattform ergänzen
Die drei Engines schließen einander nicht aus. In gewachsenen Datenplattformen ist es eher die Regel als die Ausnahme, dass alle drei nebeneinander vorkommen. Spark übernimmt die nächtlichen Pipelines, weil das Volumen über mehrere Terabyte geht oder weil bestehende Yarn-Cluster ohnehin verfügbar sind. DuckDB beantwortet ad hoc Fragen aus Notebooks, weil es kein eigenes Cluster-Setup verlangt und SQL die universelle Lingua franca für Analysten bleibt. Polars rechnet im Hintergrund von Anwendungen, die auf einem einzelnen Server bedient werden, etwa interne Dashboards oder API-Endpunkte mit aggregierten Auswertungen.
Eine Faustregel hat sich in der Praxis bewährt. Erst die Datenmenge bestimmen, dann die Latenzanforderung, dann die Engine wählen. Wer einen Job einmal pro Stunde laufen lässt und 50 GB verarbeitet, ist mit Polars auf einer Cloud-Maschine bestens bedient. Wer eine interaktive Analyse-Schicht für ein Frontend baut, sollte DuckDB ernsthaft prüfen. Wer eine ETL-Pipeline für mehrere Terabyte pro Nacht orchestriert, kommt mit Spark am weitesten.
Ein zweiter, oft übersehener Aspekt ist die Skill-Verfügbarkeit. Spark verlangt Erfahrung mit der JVM, mit Cluster-Tooling, mit dem Debuggen verteilter Systeme. Polars und DuckDB sind in einer Stunde erlernbar, wenn man Pandas oder SQL bereits kennt. Für viele Teams in der DACH-Region ist das ein gewichtiges Argument. Wer keinen Senior-Data-Engineer mit Spark-Hintergrund einstellen kann, baut sich mit Spark einen Klotz ans Bein. Polars und DuckDB sind in dieser Hinsicht deutlich gnädiger.
Meine Empfehlung für eine neue Plattform 2026: Mit Polars und DuckDB anfangen. Erst Spark einführen, wenn eine Pipeline definitiv nicht mehr auf eine Maschine passt. Diese Reihenfolge spart Komplexität, beschleunigt das Onboarding neuer Teammitglieder und verhindert, dass eine Plattform vorzeitig in einer Cluster-Tooling-Falle landet.
Fazit und Ausblick
Die Wahl der Engine hat Folgen für den Rest der Architektur. Wer Spark einsetzt, braucht ein Cluster-Tooling, ein Job-Scheduling-System und ein Monitoring-Setup für die JVM. Bei den Job-Schedulern haben sich drei Werkzeuge etabliert. Apache Airflow ist mit Version 3.0 (April 2025) und der jüngsten 3.2 deutlich runderneuert worden, mit DAG-Versionierung, Asset-Partitionierung und einem komplett überarbeiteten UI [12]. Dagster steht aktuell bei Version 1.13 und positioniert sich konsequent asset-zentriert, mit kürzlich eingeführten Virtual Assets, partitionierten Asset-Checks und mitgelieferten KI-Skills für Coding-Agenten [13]. Prefect ist Anfang 2026 bei 3.6.x angelangt, mit transaktionalen Semantiken und einer aufgeräumten Python-API [14]. Wer auf Polars oder DuckDB setzt, kommt mit einer einfacheren Infrastruktur aus. Eine einzige starke Maschine, ein klassisches Linux-Cron oder ein einfacher Workflow-Manager wie Prefect reichen oft aus.
Ein zweiter Architektur-Effekt betrifft das Tabellenformat. Spark, Polars und DuckDB lesen alle Iceberg, alle Parquet, alle direkt aus S3-Buckets. Die Wahl der Engine schließt also keine Lakehouse-Strategie aus. Im Gegenteil: Genau diese Interoperabilität macht die Architektur des modernen Data Stacks so wertvoll. Eine Iceberg-Tabelle wird in Spark erzeugt, in Polars um abgeleitete Kennzahlen ergänzt und in DuckDB von einer Analystin abgefragt, ohne dass die Daten dabei jemals umkopiert werden müssen.
Eine dritte Konsequenz: Die Engine-Wahl prägt die Kostenstruktur. Spark-Cluster sind in der Cloud teuer, weil sie viele Knoten brauchen und schwer auf null skalieren. Polars und DuckDB skalieren auf null, weil sie auf einer Maschine laufen, die sich am Tag abschalten lässt. Für Workloads mit klaren Auslastungsspitzen ist das ein erheblicher wirtschaftlicher Vorteil.
Ein vierter Aspekt verdient Beachtung. Die Engine-Wahl beeinflusst auch das Zusammenspiel mit dem Tabellenformat-Katalog. Spark spricht alle Kataloge nativ. Polars hat Iceberg-Leseunterstützung und liefert seit Ende 2025 grundlegende Schreibunterstützung für einfache Tabellen, bei komplexen Setups (etwa mit Partitionierung oder seltenen Schreibmustern) kommt es allerdings noch zu Reibungen, weshalb manche Teams für Iceberg-Writes auf Daft als Alternative zurückgreifen. DuckDB liest Iceberg über eine Erweiterung, schreibt seit der 1.4er-Linie auf nicht-partitionierten v2-Tabellen und kann auch DuckLake bedienen. In allen drei Fällen funktioniert die Integration mit Polaris als zentralem Katalog stabil. Wer eine plattformübergreifende Strategie verfolgt, ist mit dieser Kombination gut bedient.
Ein konkreter Performance-Vergleich ordnet das Bild ein. In den TPC-H-ähnlichen PDS-H-Benchmarks bei den Skalenstufen SF-10 und SF-100 sind Polars und DuckDB rund eine Größenordnung schneller als Dask und PySpark, weil der Cluster-Overhead bei diesen Datenmengen kaum etwas einspart [10]. Auf einer kleinen Vier-vCore-Maschine schlägt DuckDB Spark mit Native Execution Engine um etwa Faktor 1,6. Erst ab acht und mehr vCores zieht Spark mit NEE wieder vorbei und liefert die schnelleren Ergebnisse. Solche Zahlen geben einen Anhaltspunkt, ändern aber nichts daran, dass die Engine-Wahl letztlich am eigenen Workload entschieden gehört.
Schließlich noch eine Beobachtung zum operativen Alltag. Die größte Quelle von Frustration in produktiven Pipelines ist erfahrungsgemäß nicht die Engine selbst, sondern das Job-Scheduling. Eine gut gewählte Engine taugt wenig, wenn die orchestrierte Pipeline beim ersten Fehler schweigt, das Monitoring keine Aussage erlaubt und manuelle Restarts den Tag bestimmen. Wer eine neue Plattform aufbaut, sollte deshalb von Anfang an in Dagster, Prefect oder zumindest Airflow investieren, mit klarem Logging und Alerting. Die Engine-Wahl ist erst die zweite Frage. Die erste lautet, wie zuverlässig die Pipeline in Wartung und Betrieb läuft.
Im nächsten Teil rückt die andere Seite des Stacks in den Fokus. Wenn Antwortzeiten unter einer Sekunde gefordert sind, etwa für Dashboards oder interaktive Anwendungen, reichen weder Spark noch Polars noch DuckDB. Hier kommen analytische Datenbanken ins Spiel, allen voran ClickHouse und seine Konkurrenten aus dem Hyperscaler-Lager. Genau diese Schicht ergänzt das, was Engines aus dem Lakehouse herauslesen, um die Garantie schneller, vorhersehbarer Antwortzeiten für Anwendungen, die direkt mit Endnutzern reden.
Eine letzte Beobachtung zur Engine-Wahl gehört dazu. Die größte Verschiebung der vergangenen drei Jahre ist nicht die Ablösung von Spark, sondern die Aufweichung der Vorstellung, dass verteiltes Rechnen die Default-Wahl sein müsse. Single-Machine-Werkzeuge wie Polars und DuckDB haben die Schwelle, ab der sich ein Cluster lohnt, deutlich nach oben verschoben. Diese Verschiebung wird sich in den kommenden Jahren fortsetzen, weil die Hardware weiter wächst und die Software-Optimierungen der Single-Machine-Frameworks sehr aktiv weiterentwickelt werden.
Quellen
[1] Apache Spark Release Notes 4.1.1 und 4.2.0 Preview-Releases, Stand April 2026 (https://spark.apache.org/releases/, https://spark.apache.org/news/spark-4-2-0-preview2-released.html)
[2] Polars 1.40.1 Release auf GitHub, 22. April 2026 (https://github.com/pola-rs/polars/releases/tag/py-1.40.0)
[3] DuckDB 1.5.2 Release-Ankündigung, 13. April 2026 (https://duckdb.org/2026/04/13/announcing-duckdb-152)
[4] DuckDB Iceberg-Browser-Integration, Dezember 2025 / Januar 2026 (https://duckdb.org/2025/12/16/iceberg-in-the-browser, https://www.infoq.com/news/2026/01/duckdb-iceberg-browser-s3/)
[5] Polars User Guide Version 1 und Streaming-Konzepte, Stand April 2026 (https://docs.pola.rs/releases/upgrade/1/, https://docs.pola.rs/user-guide/concepts/streaming/)
[6] Apache Spark Connect Overview, Stand April 2026 (https://spark.apache.org/docs/4.2.0-preview1/spark-connect-overview.html)
[7] DuckDB Iceberg Writes, November 2025 (https://duckdb.org/2025/11/28/iceberg-writes-in-duckdb)
[8] Amazon EMR on EKS Cost and Performance, AWS Big Data Blog (https://aws.amazon.com/blogs/big-data/amazon-emr-on-amazon-eks-provides-up-to-61-lower-costs-and-up-to-68-performance-improvement-for-spark-workloads/)
[9] Hetzner Statement on Price Adjustment April 2026 (https://www.hetzner.com/pressroom/statement-price-adjustment/)
[10] Polars vs Spark vs DuckDB TPC-H/PDS-H Benchmark-Vergleich, Coiled-Dokumentation (https://docs.coiled.io/blog/tpch.html)
[11] Polars PDS-H Benchmark Results 2025, pola.rs (https://pola.rs/posts/benchmarks/)
[12] Apache Airflow 3.0 General Availability, April 2025, plus Airflow 3.2 Asset-Partitionierung (https://airflow.apache.org/blog/airflow-three-point-oh-is-here/, https://airflow.apache.org/blog/airflow-3.2.0/)
[13] Dagster Releases, Stand April 2026 (https://github.com/dagster-io/dagster/releases)
[14] Prefect Open Source Releases und 3.6.x Release Notes, Stand April 2026 (https://docs.prefect.io/v3/release-notes/oss/version-3-6, https://github.com/PrefectHQ/prefect/releases)