Apache Airflow

Kurzfazit

Apache Airflow ist seit Jahren der De-facto-Standard für Workflow-Orchestrierung in Data Engineering und MLOps. Wer ML-Trainingsläufe, ETL-Strecken oder ganze Datenpipelines zuverlässig planen, ausführen und überwachen will, landet fast unausweichlich bei Airflow — oder begründet, warum nicht. Mit Airflow 3.0 vom April 2025 hat das Projekt eine längst überfällige Modernisierung bekommen: DAG-Versionierung, neue React-UI, Asset-basiertes Scheduling und ein Common AI Provider für LLM-Aufrufe. Wer Python beherrscht und Pipelines als Code denken will, bekommt eines der mächtigsten Open-Source-Werkzeuge der Branche. Wer Klick-Workflows sucht, ist hier falsch.

Für wen ist Apache Airflow?

Data Engineers: Das ursprüngliche Zielpublikum und nach wie vor die größte Nutzergruppe. ETL-Strecken zwischen Snowflake, BigQuery, PostgreSQL, S3 und dbt sind in Airflow seit Jahren Standardarbeit. Die Provider-Kataloge enthalten Operators für praktisch jede gängige Datenquelle.

ML-Engineers und MLOps-Teams: Trainingspipelines, die wöchentlich neu laufen, Feature-Engineering-Strecken, Modell-Validierung und Deployment in Produktion — Airflow orchestriert die Schritte, übergibt rechenintensive Arbeit an Spark, Kubernetes oder Cloud-ML-Services und behält Status und Logs an einer Stelle. Mit dem Common AI Provider (3.0) lassen sich auch LLM-Aufrufe und Agenten-Workflows einbinden.

Plattform-Teams in Konzernen: Wenn dutzende Teams Pipelines bauen und ein zentrales Betriebsmodell gefragt ist, ist Airflow der etablierte Baukasten. Multi-Tenant-Setups mit Rollen, Audit-Logs und SSO sind über Astronomer oder eigenes Kubernetes realisierbar.

Open-Source-Verfechter und souveränitätsbewusste Teams: Apache 2.0, kein Vendor-Lock-in, läuft on-prem, in jeder Cloud, im eigenen Kubernetes. Für Banken, Versicherungen und Behörden, die nicht von einer SaaS abhängen wollen, ist das ein Argument schwerer als jedes Marketing-Versprechen.

Weniger geeignet für: Fachabteilungen ohne Python-Kompetenz (lieber n8n oder Make), Echtzeit-Streaming-Anwendungen (das ist Kafka- oder Flink-Territorium), kleine Teams ohne DevOps-Kapazität, die selbst hosten wollen, sowie alle, die einen visuellen Workflow-Designer erwarten.

Preise im Detail

Variante	Preis	Was du bekommst
Self-Hosted	0 € (Apache 2.0)	Vollständige Software, alle Features. Eigene Infrastruktur, Wartung, Updates und Backups übernimmst du selbst
Astronomer Astro Developer	ab 0,35 USD/h pro Deployment + Worker (ab 0,13 USD/h)	Pay-as-you-go, AI-gestützte DAG-Erstellung, Scale-to-Zero, API-Zugriff
Astronomer Astro Team	ab 0,42 USD/h pro Deployment	End-to-End-Observability, dedizierte Cluster, High Availability, 7-Tage-Audit-Logs, 24x5-Support
Astronomer Business / Enterprise	Auf Anfrage (Jahresvertrag)	SSO, CI/CD-Enforcement, 90-Tage-Audit, 24x7-Support mit 1h-SLA, RBAC, SCIM, Disaster Recovery
AWS MWAA	Small ab 0,49 USD/h, Large ab 0,99 USD/h (Worker, Storage extra)	Managed Airflow auf AWS, EU-Region Frankfurt verfügbar, IAM-Integration, MWAA Serverless als Pay-per-Task-Variante
Google Cloud Composer 3	ab ca. 380 USD/Monat für kleinste Umgebung (Compute, Storage, Datenbank zusammen)	Managed Airflow auf GCP, EU-Regionen verfügbar, Integration mit BigQuery, Vertex AI, Workflows

Einordnung: Self-Hosted wirkt verlockend günstig, ist es aber nur für Teams mit existierendem Kubernetes-Know-how. Realistisch sind 0,5 bis 1 FTE für laufenden Betrieb mittelgroßer Installationen. Für die meisten Unternehmen ist eine Managed-Variante die ehrlichere Wahl — die Frage ist nur welche. Astronomer ist die Airflow-Spezialfirma (geleitet von Kern-Committern) und bietet die schärfste Airflow-spezifische Erfahrung. AWS MWAA und GCP Composer sind günstiger, aber spürbar weniger reaktiv bei Airflow-Updates und liefern weniger Komfort-Features. Für KMU mit überschaubaren Pipeline-Anforderungen ist MWAA Small (rund 350 USD/Monat plus Worker) ein vernünftiger Einstiegspunkt, für Konzerne mit hohen Compliance-Anforderungen meist Astronomer Business oder Enterprise.

Stärken im Detail

Pipelines als echter Code. DAGs sind Python-Dateien, die du in Git versionierst, in Pull Requests reviewst, mit pytest testest und über CI/CD ausrollst. Diese Software-Engineering-Disziplin auf Datenpipelines anzuwenden, ist seit Airflow Standard geworden — und der Hauptgrund, warum es No-Code-Tools in produktiv kritischen Datenstrecken praktisch nicht ersetzt haben. Wer Pipelines testen, refaktorieren und reproduzierbar deployen will, kommt an Code-First-Orchestrierung nicht vorbei.

Riesiges Ökosystem an Operatoren und Hooks. Über 90 offizielle Provider-Pakete decken alles ab, was im Datenstack zählt: AWS, GCP, Azure, Snowflake, Databricks, dbt, Spark, Kubernetes, Slack, Postgres, MySQL, Salesforce, MongoDB, HuggingFace und viele mehr. Statt jede Integration selbst zu schreiben, importierst du den passenden Operator. Das spart in echten Projekten Wochen an Implementierungsaufwand.

Drei ernsthafte Managed-Optionen. Astronomer als Spezialanbieter (Airflow-Committer im Team), AWS MWAA mit Verfügbarkeit auch in Frankfurt (eu-central-1) und Google Cloud Composer mit EU-Regionen — du hast echte Wahl und musst nicht zwingend selbst hosten. Für DSGVO-Einsätze ist die EU-Hosting-Option entscheidend; alle drei Anbieter liefern AVV und Standardvertragsklauseln.

Airflow 3.0 hat Altlasten beseitigt. Mit dem Release vom 22. April 2025 wurden die größten Schmerzpunkte aus 2.x adressiert: DAG-Versionierung (mehrere Versionen einer DAG laufen parallel), Asset-basiertes Scheduling (Pipelines triggern auf Datenänderungen statt Cron), Edge Executor für verteilte Ausführung, Task SDK mit entkoppeltem Lebenszyklus, vollständig neue React-UI. Das ist nicht nur Kosmetik — DAG-Versionierung etwa war jahrelang das Argument, mit dem Konkurrenten wie Dagster gegen Airflow geworben haben. Diese Lücke ist geschlossen.

Maturität und Verbreitung. Airbnb startete das Projekt 2014, Apache-Top-Level seit 2019, in praktisch jedem ernsthaften Datenstack der Welt vertreten. Stack-Overflow-Antworten, Konferenz-Talks, Bücher, geschulte Engineers — die Community ist die größte im Bereich Workflow-Orchestrierung. Das ist für Onboarding und Risikoabschätzung ein nicht zu unterschätzender Vorteil.

Schwächen ehrlich betrachtet

Steile Lernkurve, besonders am Anfang. Wer von einem visuellen Workflow-Tool kommt, muss sich durch eine ganze Konzepthierarchie arbeiten: DAGs, Tasks, Operators, Hooks, Sensors, Executors, XCom, Connections, Variables, Pools. Die offizielle Doku ist gut, aber umfangreich. Realistisch sind zwei bis vier Wochen, bis ein erfahrener Python-Entwickler produktiv eigene Pipelines baut — und Wochen mehr, bis Operations-Themen (Logging, Retries, SLAs, Backfills) sitzen.

Self-Hosting ist kein Wochenend-Projekt. Du brauchst PostgreSQL als Metadatenbank, einen Executor (LocalExecutor reicht nicht für Produktion — Celery mit Redis oder Kubernetes-Executor), getrennten Webserver, Scheduler, Worker, Logging-Strategie, Backup-Konzept, Authentifizierung, TLS, Updates. Wer das nicht erfahrenem Plattform-Team gibt, bekommt entweder eine instabile Installation oder hohe versteckte Kosten. Für die meisten Teams ist Managed günstiger als selbst gerechnet.

Konkurrenz hat moderner gestartet. Prefect und Dagster sind später entstanden und haben einige Designentscheidungen aufgeräumt: Decorator-basierte Syntax statt expliziter Operator-Klassen, dynamischere Pipelines, bessere Observability per Default, durable execution mit automatischem Resume. Für neue grüne-Wiese-Projekte sind beide ernstzunehmend — und Teams, die Frust mit klassischer Airflow-Syntax hatten, wechseln gelegentlich. Airflow 3.0 hat aufgeholt, aber die Konkurrenz steht nicht still.

Keine deutschen Support- oder UI-Optionen. Dokumentation, Community, alle drei Managed-Anbieter sind englischsprachig. Die UI lässt sich nicht auf Deutsch umstellen. Für deutsche Teams meist akzeptabel (Engineering-Tools sind selten deutschsprachig), aber bei Schulungen für nicht-englischsprachige Mitarbeitende ein Faktor.

Migration auf 3.0 ist Arbeit. Wer auf 2.x produktiv läuft, muss für den Sprung auf 3.0 nicht-triviale Migrationsarbeit leisten — Breaking Changes bei Executor-Konfiguration, Datenbank-Zugriff, einigen Provider-APIs. Viele Teams hängen aktuell noch auf 2.10.x. Bei Managed-Services hilft der Anbieter (Astronomer aktiv, MWAA und Composer eher reaktiv), bei Self-Hosting trägst du es allein.

Alternativen im Vergleich

Wenn du…	…nimm stattdessen
Eine Plattform für klassisches Data-Engineering UND Spark/ML aus einer Hand willst	Databricks
Managed ML-Pipelines auf AWS bauen willst, ohne Airflow-Komplexität	Amazon SageMaker
Workflow-Automatisierung ohne Programmierkenntnisse aufsetzen willst	n8n oder Make
Einfache SaaS-zu-SaaS-Integrationen ohne ETL-Anspruch brauchst	Zapier
Modernere Code-First-Orchestrierung mit Decorator-Syntax willst	Prefect oder Dagster (keine eigene Tool-Seite)

Erwähnenswert ohne eigene Tool-Seite: Prefect (Decorator-basiert, durable execution, event-driven), Dagster (Asset-zentrierte Sicht, gute Observability), Argo Workflows (Kubernetes-nativ, YAML-DAGs) und Temporal (eher für Application-Workflows als Datenpipelines). Für reine ML-Orchestrierung sind Kubeflow und MLflow eigene Welten — sie überlappen mit Airflow, ersetzen es aber selten vollständig. Airflow bleibt im Markt der Default, gegen den sich alle anderen positionieren.

So steigst du ein

Schritt 1: Lokal starten mit dem offiziellen Quickstart. Installiere Airflow per pip install apache-airflow in einem Python-Venv oder noch besser per Docker Compose nach dem offiziellen Quickstart. Schreibe deine erste DAG mit drei Tasks — etwa BashOperator für „echo hello”, PythonOperator für eine Funktion, dann ein Verbund per >>-Operator. Schaue dir den Lauf in der UI an. Spätestens hier verstehst du, warum Pipelines als Code überlegen sind.

Schritt 2: Echte Datenstrecke nachbauen. Wähle einen realen Anwendungsfall — etwa täglich CSV-Dateien aus S3 holen, transformieren, in PostgreSQL laden. Nutze die offiziellen Provider (apache-airflow-providers-amazon, apache-airflow-providers-postgres) statt eigene Hooks zu schreiben. Lerne dabei: Connections, Variables, XCom für Datenweitergabe, Sensors für Wartelogik, Retries und SLAs für Robustheit.

Schritt 3: Managed-Service evaluieren, bevor produktiv. Spätestens vor dem Produktiveinsatz ehrlich rechnen: Was kostet Self-Hosting (Server, Backups, Personal-Zeit) versus Astronomer Developer oder MWAA Small? In den meisten KMU-Szenarien gewinnt Managed deutlich. Nur wenn du ohnehin ein erfahrenes Plattform-Team mit Kubernetes betreibst, lohnt Self-Hosting wirtschaftlich.

Ein konkretes Beispiel

Ein deutsches E-Commerce-Unternehmen aus Köln (180 Mitarbeitende) betreibt eine ML-gestützte Produktempfehlung. Datenpipeline auf Airflow, gehostet via Astronomer in Frankfurt: Täglich um 03:00 Uhr extrahiert eine DAG Bestelldaten aus PostgreSQL und Klickstream-Events aus S3, transformiert sie mit dbt in Snowflake, übergibt das Trainings-Dataset an einen Sagemaker-Trainingsjob, validiert das resultierende Modell gegen einen Holdout-Set und deployed es bei bestandener Validierung in den Produktions-Endpoint. Die ganze DAG läuft in 90 Minuten, Fehler werden in Slack gemeldet, jede Version des Modells ist in MLflow registriert. Effekt: Was vorher als Cron-Job-Sammlung mit drei Tools koordiniert wurde, läuft jetzt als versionierter Workflow mit klarer Verantwortung. Bei Fehlern findet das Team in der Airflow-UI in Minuten die Ursache statt durch Server-Logs zu graben. Das Team aus zwei Data Engineers und einem ML Engineer hält die Plattform mit ca. 20 % Kapazität am Laufen — Astronomer übernimmt Updates, Worker-Skalierung und Backups.

DSGVO & Datenschutz

• Datenhosting: Vollständig in deiner Hand. Self-Hosted: läuft, wo du es betreibst (on-prem, eigene Cloud, Kubernetes). Astronomer bietet Hosting in EU (Frankfurt, Irland) wählbar. AWS MWAA in Frankfurt (eu-central-1) verfügbar. Google Cloud Composer in europe-west1, europe-west3 (Frankfurt) und weiteren EU-Regionen.
• Datennutzung: Apache Airflow als Open-Source-Projekt sendet keine Telemetrie an Dritte (Standardkonfiguration). Bei Managed-Diensten: jeweiliger Cloud-Anbieter-AVV regelt Auftragsverarbeitung.
• Auftragsverarbeitung (AVV): Bei Astronomer, AWS und Google Cloud verfügbar — Standardgeschäft in den jeweiligen Enterprise-Verträgen.
• Sensible Daten in DAGs: Niemals als Klartext im DAG-Code committen. Nutze Airflow Connections und Secrets-Backends (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager). Achtung: XCom-Daten landen in der Metadatenbank — keine personenbezogenen Daten unverschlüsselt darüber transportieren.
• Empfehlung für DSGVO-sensible Branchen: Self-Hosting on-prem oder in deiner eigenen Cloud-Region ist der sauberste Pfad — du hast volle Kontrolle. Bei Managed: Astronomer mit explizit EU-Hosting wählen oder MWAA/Composer in Frankfurt. Vor Produktiveinsatz Datenschutz-Folgenabschätzung durchführen, besonders wenn personenbezogene Daten durch die Pipeline fließen.

Gut kombiniert mit

• Databricks — Airflow orchestriert übergreifend (Trigger, Abhängigkeiten, Validierung), Databricks führt rechenintensive Spark-Jobs und ML-Trainings aus. Über den Databricks-Provider startest du Notebooks und Jobs aus DAGs, Status fließt in die Airflow-UI zurück. Saubere Aufgabenteilung.
• Amazon SageMaker — Airflow-DAGs koordinieren Trainings-, Tuning- und Batch-Inferenz-Jobs in SageMaker. Der apache-airflow-providers-amazon-Operator deckt die wichtigsten SageMaker-Aktionen ab. Für Teams im AWS-Ökosystem natürliche Kombination.
• dbt (kein eigener Tool-Eintrag) — der Standard für Datenmodellierung in modernen Stacks. Airflow plant und triggert dbt-Runs, dbt selbst transformiert in Snowflake/BigQuery. Astronomer Cosmos macht die Integration besonders schmerzarm — jedes dbt-Modell wird automatisch zu einer Airflow-Task.

Unser Testurteil

Apache Airflow verdient 4 von 5 Sternen. Es ist der reife, verbreitete und seriöse Standard für Workflow-Orchestrierung — mit dem 3.0-Release sind die wichtigsten Schwächen der letzten Jahre adressiert. Den fünften Stern verliert es durch die Einstiegshürden (steile Lernkurve, komplexes Self-Hosting) und durch die Tatsache, dass jüngere Konkurrenz wie Prefect und Dagster in Bedienkomfort und Entwickler-Erfahrung in einigen Aspekten die Nase vorn hat. Wer aber heute eine produktive ML- oder Datenpipeline bauen muss und nicht aus politischen Gründen zwingend etwas anderes nehmen will, fährt mit Airflow — idealerweise als Managed Service — die sicherste Strecke. Die Reife des Ökosystems wiegt manche Bedienkomfort-Lücke auf.

Was wir bemerkt haben

• April 2025 — Apache Airflow 3.0 wurde am 22. April 2025 veröffentlicht. Das ist der größte Architektur-Sprung seit Airflow 2.0 (2020): DAG-Versionierung, neue React-UI, Asset-basiertes Scheduling, Task SDK und ein Common AI Provider für LLM-Workflows. Viele Teams haben die Migration noch vor sich.
• 2024–2025 — Astronomer ist die Airflow-Beraterfirma der Wahl geworden und hat 2024 deutlich zugelegt — viele Kern-Committer arbeiten dort. Das stärkt Airflow nachhaltig, schafft aber auch eine kommerzielle Konzentration im Open-Source-Projekt, die Beobachter aufmerksam verfolgen.
• 2025 — Airflow 3.0 hat einen Common AI Provider eingeführt, der LLM-Aufrufe und Agenten-Workflows als first-class-Bürger integriert. Damit positioniert sich das Projekt explizit auch als Orchestrator für agentische und ML-Workloads — nicht nur für klassisches ETL.
• Mai 2026 — Aktuelle stabile Version ist Airflow 3.2.x. Der 3.x-Branch ist seit über einem Jahr produktiv erprobt. Wer neu startet, sollte direkt auf 3.x gehen — 2.x bekommt nur noch Security-Patches in Long-Term-Support-Versionen.
• 2024 — Prefect und Dagster haben mit Decorator-Syntax und durable execution Druck auf Airflow gemacht. Dass Airflow 3.0 zentrale Lücken (DAG-Versionierung, Asset-Scheduling) geschlossen hat, ist auch eine direkte Antwort auf diese Konkurrenz — gut für die Nutzerinnen und Nutzer.