Airflow vs Dagster vs Prefect: Orchestrator-Vergleich 2026

Einen Orchestrator zu wählen ist eine dieser Entscheidungen, die leicht zu hinterfragen und schmerzhaft zurückzudrehen sind. Airflow, Dagster und Prefect sind die drei Tools, die in praktisch jedem Data-Team-Gespräch auftauchen — sie lösen dasselbe Problem aus sehr unterschiedlichen Winkeln. Dieser Vergleich kürt keinen Gewinner. Es gibt nur den richtigen Fit für die spezifischen Constraints deines Teams.

TL;DR

• Airflow: Reifster, größte Community, bestes Operator-Ökosystem — aber Local-Dev ist mies und der Scheduler will Pflege.
• Dagster: Asset-zentrisch, eingebaute Lineage und Catalog — die beste Wahl für neue Data-Plattformen.
• Prefect: Stärkste Developer-Experience, dynamische Workflows, Python-nativ — Local-Run ohne Docker.
• Entscheidungs-Faustregel: Bestehendes Team → Airflow. Neuer Platform-Build mit Asset-Fokus → Dagster. Python-natives Team mit dynamischen Flows → Prefect.

Apache Airflow

Airflow wurde 2014 bei Airbnb gebaut und an die Apache Software Foundation gespendet. Es ist der meistdeployte Orchestrator weltweit — das bedeutet mehr Stack-Overflow-Antworten, mehr Helm-Charts, und mehr Engineers, die es schon kennen.

Architektur

Airflow ist um DAGs (Directed Acyclic Graphs) gebaut, definiert als Python-Files. Der Scheduler liest diese Files, ermittelt, was laufen muss, und dispatched Tasks an Worker. Der Webserver liefert die UI fürs Monitoring. Eine Metadata-DB (typischerweise PostgreSQL) speichert die Run-Historie.

# Apache Airflow 2.x: ein minimaler DAG
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime

def extract():
    print("Extracting data...")

def load():
    print("Loading data...")

with DAG(
    dag_id="simple_etl",
    start_date=datetime(2024, 1, 1),
    schedule="@daily",
    catchup=False,
) as dag:
    t_extract = PythonOperator(task_id="extract", python_callable=extract)
    t_load    = PythonOperator(task_id="load",    python_callable=load)

    t_extract >> t_load

Stärken

Operator-Ökosystem. Airflow hat hunderte Providers — vorgebaute Operators für jeden großen Cloud-Service, jede DB, jedes SaaS-Tool. Wenn du etwas anbinden musst, gibt es wahrscheinlich ein Provider-Paket dafür.

Community und Hiring. Der Talent-Pool ist groß. Beim Team-Building findest du Airflow-Wissen leichter am Markt als Dagster- oder Prefect-Expertise.

Battle-tested at Scale. Große Organisationen laufen Airflow seit Jahren in seriösem Scale (tausende DAGs, Millionen Task-Runs/Tag). Die Failure-Modes sind bekannt.

Schwächen

Local-Dev ist schmerzhaft. Airflow lokal laufen lassen heißt mindestens Docker-Compose. Die Feedback-Loop ist langsam — DAG ändern, warten, bis Scheduler es aufnimmt, in der UI debuggen.

Das DAG-Parsing-Problem. Airflow parsed jedes DAG-File regelmäßig, um Änderungen zu erkennen. Komplexe DAGs mit Imports oder DB-Calls im Top-Level-Scope können den Scheduler deutlich verlangsamen. Klassischer Footgun.

Keine native Asset-Awareness. Airflow orchestriert Tasks, nicht Daten-Assets. Es gibt kein eingebautes Konzept „dieser DAG produziert Table X". Data-Lineage braucht externe Tools (OpenLineage, Marquez) oder Airflows experimentelles Dataset-Feature.

Scheduler-Komplexität. Den Airflow-Scheduler unter Last zu betreiben, braucht Tuning. HA-Setups bringen Ops-Overhead.

Managed-Optionen

• Amazon MWAA — fully managed, tiefe AWS-Integration, eingeschränkte Flexibilität
• Google Cloud Composer — managed auf GKE, historisch langsamere Upgrades
• Astronomer — der operator-freundlichste managed Airflow, stärkster Ökosystem-Support

Dagster

Dagster wurde 2019 gegründet, mit klarer These: Das richtige Primitiv für Data-Orchestrierung ist das Daten-Asset, nicht der Task. Statt Jobs als Sequenzen von Operationen zu definieren, definierst du Software-Defined Assets (SDAs) — Python-Funktionen, die je ein Stück Daten beschreiben, dessen Dependencies und Metadata.

Architektur

Dagster läuft als Webserver (Dagit/Dagster+), Daemon fürs Scheduling, und trennt Code in „Code Locations", die in isolierten Environments laufen können. Der Asset-Graph ist das zentrale Organisations-Konzept.

# Dagster: software-defined assets
from dagster import asset, AssetIn
import pandas as pd

@asset
def raw_orders() -> pd.DataFrame:
    # Rohorders vom Source-System holen.
    # In der Praxis: Read aus DB oder API
    return pd.DataFrame({"order_id": [1, 2, 3], "amount": [100, 200, 150]})

@asset(ins={"raw_orders": AssetIn()})
def validated_orders(raw_orders: pd.DataFrame) -> pd.DataFrame:
    # Orders filtern und validieren.
    return raw_orders[raw_orders["amount"] > 0]

@asset(ins={"validated_orders": AssetIn()})
def order_summary(validated_orders: pd.DataFrame) -> dict:
    # Summary-Statistiken berechnen.
    return {
        "total_orders": len(validated_orders),
        "total_revenue": validated_orders["amount"].sum()
    }

Dagster leitet den Dependency-Graph automatisch aus den Funktions-Signaturen ab. Run dagster asset materialize --select order_summary und Dagster führt die vollständige Upstream-Kette aus, trackt, welche Assets stale sind und neu materialisiert werden müssen.

Stärken

Asset-first Observability. Die Dagster-UI zeigt dir einen Catalog aller Daten-Assets, deren letzte Materialisierungs-Zeit, Freshness und Lineage. Nativ — du musst nichts dranschrauben.

Type-System und Metadata. Dagster ermutigt, Assets mit Types, Descriptions und IO-Managern zu annotieren. Metadata (Row-Counts, Schema, Custom-Metriken) wird pro Materialisierung erfasst und in der UI sichtbar. Das schließt die Lücke zwischen Orchestration und Data-Catalog.

Local-Dev. dagster dev startet eine vollständige lokale Umgebung in Sekunden. Feedback-Loop ist schnell. Assets testen ist straightforward — sie sind einfach Python-Funktionen.

Code-Isolation. Mehrere Code-Locations können in getrennten Python-Environments (oder Containern) laufen, was unterschiedliche Dependency-Sets für unterschiedliche Plattform-Teile ermöglicht.

Schwächen

Steilere Initial-Lernkurve. Das Asset-Paradigma ist Engineers, die aus Airflow kommen, fremd. Die Konzepte von IO-Managern, Resources, Partitions und Sensors brauchen Zeit.

Kleineres Operator-Ökosystem. Dagster hat First-Party-Integrationen für die großen Cloud-Provider und Tools, aber die Breite des Airflow-Provider-Ökosystems ist unerreicht.

Schwergewichtig für einfache Use-Cases. Bei 10 einfachen ETL-Jobs fühlt sich Dagsters Architektur an, als würdest du eine Data-Plattform bauen, obwohl du nur einen Scheduler wolltest.

Managed-Option relativ neu. Dagster+ reift, hat aber weniger operationalen Track-Record als Astronomer.

Wann Dagster glänzt

Dagster ist die stärkste Wahl, wenn du eine Data-Plattform baust, in der Data-Lineage, Asset-Freshness und Observability First-Class-Concerns sind. Wenn dein Team bereits in Begriffen wie „wir brauchen einen Data-Catalog" und „wir wollen wissen, was stale ist" denkt, gibt dir Dagster beides in einem Tool.

Prefect

Prefect wurde 2018 gegründet, mit Fokus auf Developer-Experience und Flexibilität. Das Prefect-2.x-Rewrite (Orion) war eine signifikante Abweichung von 1.x — hin zu einem Python-nativen, dynamischen Workflow-Modell rund um Flows und Tasks.

Architektur

Prefect trennt Control-Plane (API-Server, UI, Work-Queue-Management) von Execution-Plane (Worker, die Flows ausführen). In Prefect Cloud hostet Prefect die Control-Plane. Im Self-hosted-Modus läufst du den Server selbst.

# Prefect 2.x: ein Flow mit Tasks und Error-Handling
from prefect import flow, task
from prefect.tasks import task_input_hash
from datetime import timedelta

@task(cache_key_fn=task_input_hash, cache_expiration=timedelta(hours=1))
def extract_orders(start_date: str) -> list:
    # Orders seit start_date holen. Real-Implementierung: API-Call.
    return [{"order_id": 1, "amount": 100}]

@task(retries=3, retry_delay_seconds=30)
def validate_orders(orders: list) -> list:
    # Order-Records validieren.
    return [o for o in orders if o["amount"] > 0]

@task
def load_to_warehouse(orders: list) -> int:
    # Orders ins Ziel-Warehouse laden.
    print(f"Loading {len(orders)} orders")
    return len(orders)

@flow(name="orders-pipeline", log_prints=True)
def orders_pipeline(start_date: str = "2024-01-01"):
    raw = extract_orders(start_date)
    validated = validate_orders(raw)
    count = load_to_warehouse(validated)
    print(f"Loaded {count} orders")

if __name__ == "__main__":
    orders_pipeline(start_date="2024-03-01")

Der entscheidende Unterschied: Ein Prefect-Flow ist als reines Python-Script ausführbar (python my_flow.py). Kein lokaler Server für die Entwicklung. Das ist ein deutlicher UX-Vorteil.

Stärken

Exzellente Developer-Experience. Flows sind einfach Python. Lokal laufen lassen, mit Standard-Python-Debugger debuggen, kein Docker nötig. Die enge Feedback-Loop macht Iteration schnell.

Dynamische Workflows. Anders als Airflows statische DAGs (vollständig vor Execution definiert) können Prefect-Flows Tasks dynamisch zur Laufzeit erstellen. Stark für variable Fan-Out-Patterns.

Native Caching. Task-Level-Caching mit konfigurierbarer Expiration ist eingebaut. Re-Runs nutzen gültige Task-Results, das beschleunigt Entwicklung.

Deployment-Modell. Prefects Deployment-Modell (Flow-Code + Work-Pools + Worker) ist flexibel und cloud-native. Flows laufen auf Kubernetes, Serverless, oder jedem prozess-basierten Worker.

Prefect Cloud UI. Die managed Control-Plane hat eine saubere, nützliche UI mit Flow-Run-Historie, Scheduling und Observability.

Schwächen

Weniger Asset-Awareness als Dagster. Prefect ist Flow/Task-zentrisch. Asset-Lineage ist kein natives Konzept (obwohl Prefect Asset-Support nachrüstet).

Kleineres Operator-Ökosystem als Airflow. Prefect-Integrationen wachsen, aber die Breite der Airflow-Providers ist für Nischen-Quellen weiter größer.

Cloud vs. Self-hosted Gap. Managed Prefect Cloud ist deutlich besser als Self-hosted. Self-hosting bringt Ops-Overhead.

Weniger Referenz-Architekturen at Scale. Verglichen mit Airflow gibt es weniger dokumentierte Beispiele sehr großer Prefect-Deployments. Failure-Modes at Scale sind weniger dokumentiert.

Head-to-Head-Vergleich

Wann du was wählst

Airflow wählen, wenn:

• Dein Team es bereits nutzt und Migrations-Kosten höher sind als der Alternativ-Vorteil
• Du das breiteste Operator-Ökosystem für ungewöhnliche Source/Target-Systems brauchst
• Du in einer regulierten Umgebung bist, wo battle-tested = weniger Risiko
• Hiring ein Constraint ist und Airflow-Wissen lokal leichter verfügbar

Dagster wählen, wenn:

• Du eine neue Data-Plattform from scratch baust
• Data-Lineage, Freshness-Tracking und Asset-Observability Core-Requirements sind
• Dein Team Software-Engineering-Disziplin schätzt (Types, Testing, Code-Isolation)
• Du eine zerklüftete Sammlung von Scripts ersetzt und einen vereinheitlichten Catalog willst

Prefect wählen, wenn:

• Developer-Experience Top-Priorität ist
• Deine Workflows dynamisch / parametrisiert sind und nicht ins statische DAG-Modell passen
• Du die schnellste lokale Iterations-Loop willst
• Du ein Python-natives Team bist, das YAML-lastige Tools frustrierend findet

Migrations-Realität

Zwischen Orchestratoren zu wechseln ist kein Wochenend-Projekt. Erwarte:

• Re-Implementation aller bestehenden Jobs im neuen Paradigma
• Scheduling-Konfigurationen neu bauen
• Team-Retraining
• Parallel-Betrieb beider Systeme während der Transition (teuer)

Nicht migrieren wegen Ästhetik. Migrieren, wenn das aktuelle Tool Fortschritt aktiv blockiert.

FAQ

Welcher Orchestrator ist am günstigsten? Self-hosted Airflow ist Infrastruktur-only günstig, aber Ops-teuer. Prefect Cloud Free-Tier startet bei 0 €/Monat (kleine Workloads), Dagster+ ab ca. 0 € für Solo. Managed Airflow (MWAA) startet ca. 350 €/Monat.

Lohnt sich die Migration von Airflow zu Dagster? Nur wenn Asset-Lineage und Observability deine Core-Pain-Points sind. Sonst typischerweise nicht — Migrations-Kosten sind hoch.

Welcher ist am besten für dbt-Integration? Alle drei haben dbt-Integrations. Dagster hat die tiefste (dbt-Models als Assets sichtbar in der Lineage), Airflow mit Astro/Cosmos die ausgereifteste, Prefect die schlankste.

Was ist mit Streaming-Workloads? Keiner der drei ist ein echter Streaming-Engine. Für Streams: Kafka, Flink, oder Spark Structured Streaming. Orchestratoren triggern Batch-/Micro-Batch-Jobs.

Fazit

Alle drei sind solide Tools. Airflow gewinnt bei Ökosystem und Tenure. Dagster bei Asset-zentrischer Observability. Prefect bei Developer-Experience und dynamischen Workflows. Der beste Orchestrator ist der, den dein Team tatsächlich gut nutzen wird — wähle nach Team-Prioritäten, nicht nach Benchmarks oder Conference-Talks.

Fürs Monitoring nach der Orchestrator-Wahl: Data Pipeline Monitoring.

Weiterlesen

• Data Pipeline Monitoring
• ETL vs ELT: Welches Pipeline-Pattern passt zu deinem Stack?
• Was ist dbt?

Stand: 14. Mai 2026. Versionen und Features ändern sich — kritische Annahmen direkt beim Provider verifizieren.