Der Begriff, der die Kategorie am besten beschreibt, lautet Workflow-Orchestrierung. Airflow ist der Dirigent, der viele einzelne Aufgaben – ein Skript hier, eine Datenbankabfrage dort, ein Transfer in ein Data-Warehouse – zu einem verlässlichen, wiederholbaren Gesamtablauf zusammenführt. Entstanden ist das Projekt 2014 bei Airbnb, um dortige Datenprozesse beherrschbar zu machen. Heute steht es unter dem Dach der Apache Software Foundation und gilt in vielen datengetriebenen Organisationen als De-facto-Standard für die Orchestrierung von Batch-Pipelines.
Das zentrale Konzept ist der DAG – ein gerichteter azyklischer Graph (englisch Directed Acyclic Graph). Er beschreibt, welche Aufgaben es gibt und in welcher Reihenfolge sie voneinander abhängen. Wichtig ist das Wort azyklisch: Der Graph darf keine Schleifen enthalten, ein Schritt kann also nicht auf sich selbst zurückverweisen. So ist immer eindeutig, wann welcher Schritt starten darf – nämlich dann, wenn alle Schritte, von denen er abhängt, erfolgreich waren.
Der wohl wichtigste Unterschied zu klickbaren No-Code-Werkzeugen ist die Philosophie Workflows as Code. In Airflow werden Abläufe in Python geschrieben, nicht in einer grafischen Oberfläche zusammengeklickt. Das klingt zunächst nach einer Hürde – und ist es für Nicht-Techniker auch. Für datengetriebene Teams ist es jedoch die eigentliche Stärke: Ein als Code definierter Workflow lässt sich versionieren, in der Code-Verwaltung nachvollziehen, im Team überprüfen, automatisiert testen und in mehreren Umgebungen identisch ausrollen. Fehler werden reproduzierbar, Änderungen sind dokumentiert, und der Ablauf ist nicht in einem Klick-Werkzeug gefangen, sondern liegt als lesbarer Quelltext vor.
Diese Eigenschaft macht Airflow zu einem Werkzeug für ein anderes Publikum als klassische Automatisierungsplattformen. Wo ein No-Code-Tool die Fachabteilung anspricht, richtet sich Airflow an Data-Engineers, Data-Teams und technische Fachbereiche, die mit strukturierten Datenprozessen arbeiten. Es ist kein Werkzeug, mit dem die Marketing-Abteilung mal eben zwei Apps verbindet, sondern das Rückgrat für wiederkehrende, geschäftskritische Datenverarbeitung.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Airflow lohnt sich für Organisationen, die regelmäßig strukturierte Datenprozesse betreiben: Daten aus mehreren Quellen zusammenführen, aufbereiten und in ein Data-Warehouse oder Berichtssystem laden, nächtliche Verarbeitungsläufe steuern, Machine-Learning-Trainings orchestrieren oder komplexe Berechnungsketten verlässlich wiederholen. Überall dort, wo viele Einzelschritte in fester Reihenfolge und mit klaren Abhängigkeiten ablaufen müssen, ist Airflow in seinem Element.
Weniger geeignet ist Airflow, wenn es nur darum geht, ohne technischen Aufwand zwei Cloud-Apps zu verbinden, wenn Ereignisse in Echtzeit reagieren sollen oder wenn im Unternehmen keinerlei Entwicklungs- und Betriebskompetenz vorhanden ist. Für diese Fälle gibt es leichtgewichtigere oder stärker verwaltete Alternativen, die wir in Kapitel 06 abgrenzen. Airflow ist bewusst ein Werkzeug für den Batch-Betrieb geplanter Daten-Pipelines – und nicht die eierlegende Wollmilchsau für jede Form der Automatisierung.
Der Kern ist das Apache-Projekt selbst: freie Software unter der Apache-2.0-Lizenz, entwickelt von einer großen, aktiven Community und getragen von der Apache Software Foundation. Jeder darf Airflow herunterladen, betreiben, anpassen und weitergeben. Es entstehen keine Lizenzgebühren für die Software selbst. Kosten und Aufwand entstehen ausschließlich durch den Betrieb – also durch die Infrastruktur und die Menschen, die sie betreuen.
Die grundlegendste Bezugsform ist der Eigenbetrieb: Man installiert Airflow auf eigener Infrastruktur – auf einem Server, in der eigenen Cloud-Umgebung oder auf einem Container-Cluster. Diese Variante bietet maximale Kontrolle und Datenhoheit, verlangt aber auch die vollständige Verantwortung für Installation, Aktualisierung, Absicherung, Skalierung und Ausfallsicherheit. Für Organisationen mit ausgeprägter Betriebskompetenz ist das der Weg mit den geringsten laufenden Softwarekosten und der größten Souveränität.
Weil der Eigenbetrieb anspruchsvoll ist, hat sich ein Markt an Managed-Angeboten gebildet. Sie nehmen einem den Betrieb ganz oder teilweise ab – gegen ein nutzungs- oder kapazitätsabhängiges Entgelt. Qualitativ lassen sich die verbreitetsten Optionen so einordnen:
Weil die Software selbst kostenlos und überall gleich ist, verlagert sich die eigentliche Entscheidung auf die Betriebsform. Sie bestimmt die laufenden Kosten, den Personalbedarf, die Ausfallsicherheit und – für viele Mittelständler zentral – den Serverstandort und damit die datenschutzrechtliche Bewertung. Ein selbst betriebenes Airflow in einem deutschen Rechenzentrum ist datenschutzrechtlich anders zu bewerten als derselbe Airflow-Kern als verwalteter Dienst in der Cloud eines US-Anbieters. Diese Verbindung zwischen technischem Kern und Betriebsform behalten wir über den gesamten Artikel im Blick.
Das Zusammenspiel lässt sich an einem typischen Beispiel gut nachvollziehen. Ein DAG beschreibt einen nächtlichen Datenlauf: Zuerst werden Rohdaten aus mehreren Quellen geladen, danach werden sie bereinigt und zusammengeführt, anschließend in ein Data-Warehouse geschrieben und zum Schluss wird ein Bericht erzeugt. Jeder dieser Schritte ist ein Task, gebildet aus einem passenden Operator. Die Reihenfolge und die Abhängigkeiten sind im DAG festgelegt: Der Bericht darf erst laufen, wenn das Schreiben ins Warehouse erfolgreich war.
Der Scheduler prüft, ob der definierte Startzeitpunkt erreicht ist und ob die Vorbedingungen jedes Tasks erfüllt sind. Sobald ein Task startklar ist, übergibt der Executor ihn zur Ausführung – je nach Konfiguration lokal, auf verteilten Workern oder als isolierter Container. Die gesamte Ausführung, jeder Erfolg und jeder Fehler, wird protokolliert und ist in der Web-UI sichtbar. Schlägt ein Task fehl, kann Airflow ihn nach definierten Regeln automatisch wiederholen und im Zweifel eine Benachrichtigung auslösen.
Drei Fähigkeiten machen Airflow im Datenalltag besonders wertvoll. Retries bedeuten, dass ein fehlgeschlagener Task automatisch mehrfach wiederholt wird, bevor der Ablauf als gescheitert gilt – wichtig bei kurzfristigen Störungen wie einer nicht erreichbaren Datenbank. Backfilling erlaubt es, einen Ablauf rückwirkend für vergangene Zeiträume nachzuholen, etwa wenn eine Pipeline neu eingeführt wird und die Daten der letzten Wochen ebenfalls verarbeitet werden sollen. Und die angestrebte Idempotenz – also dass ein mehrfach ausgeführter Schritt zum selben Ergebnis führt – ist ein Grundprinzip beim Entwurf robuster Pipelines. Diese Eigenschaften sind der Grund, warum Airflow für verlässliche, wiederholbare Datenprozesse so geschätzt wird.
Der Unterschied ist wichtig für die Erwartungshaltung: Airflow „macht“ keine KI, sondern koordiniert die Werkzeuge, die KI machen. Das eigentliche Modelltraining, die Datenaufbereitung oder ein KI-Aufruf laufen in spezialisierten Systemen; Airflow sorgt dafür, dass diese Schritte zuverlässig ausgelöst, in der richtigen Abfolge verkettet und überwacht werden. In der Sprache datengetriebener Teams ist Airflow damit ein zentraler Baustein für reproduzierbare Datenautomatisierung.
Ein Machine-Learning-Vorhaben besteht selten aus einem einzelnen Schritt. Typisch ist eine Kette: Daten sammeln, bereinigen, Merkmale berechnen, ein Modell trainieren, die Güte prüfen und – wenn sie ausreicht – das Modell bereitstellen. Jeder dieser Schritte hat Abhängigkeiten, kann fehlschlagen und muss reproduzierbar sein. Genau dafür ist Airflow gebaut. Als DAG abgebildet, wird aus einer Sammlung verstreuter Skripte ein nachvollziehbarer, wiederholbarer Prozess, dessen Zustand jederzeit sichtbar ist und der bei Fehlern kontrolliert reagiert.
Der Mehrwert liegt weniger in der KI selbst als in der Verlässlichkeit und Nachvollziehbarkeit. Wenn ein Modelltraining nachts fehlschlägt, weil eine Datenquelle nicht erreichbar war, wiederholt Airflow den Schritt nach Regeln, bricht bei anhaltendem Fehler kontrolliert ab und benachrichtigt das Team. Das ist der Unterschied zwischen einem hoffentlich funktionierenden Skript und einem beherrschbaren Produktivprozess.
Über KI hinaus ist die klassische Datenautomatisierung das eigentliche Zuhause von Airflow. Das verbreitete Muster ist die sogenannte ELT- oder ETL-Pipeline: Daten aus verschiedenen Quellen extrahieren, in ein zentrales System laden und dort transformieren. Airflow orchestriert diese Schritte, koordiniert die Abhängigkeiten und stellt sicher, dass nachgelagerte Auswertungen erst auf vollständigen, aktuellen Daten aufsetzen. Für Berichtswesen, Kennzahlen-Dashboards und datengetriebene Entscheidungen ist diese verlässliche Aktualisierung die unsichtbare, aber entscheidende Grundlage.
Zunehmend werden auch Aufrufe an KI-Dienste zu einem Schritt innerhalb einer Airflow-Pipeline – etwa um große Mengen an Texten stapelweise zu klassifizieren, zusammenzufassen oder anzureichern. Airflow eignet sich für solche Stapelverarbeitungen gut, weil es die Aufrufe steuern, bei Fehlern wiederholen und die Kosten- sowie Mengensteuerung an einer zentralen Stelle bündeln kann. Wichtig ist dabei die datenschutzrechtliche Betrachtung: Sobald Daten an einen externen KI-Dienst übergeben werden, verlassen sie die eigene Umgebung – das ist gesondert zu bewerten, wie wir in Kapitel 09 ausführen.
Anders als bei No-Code-Plattformen, deren Integrationen fertig verpackt sind, kommen die Anbindungen bei Airflow als Provider-Packages: erweiterbare Pakete, die zusätzliche Operators, Verbindungen und Sensoren für ein bestimmtes System mitbringen. Man installiert das Paket für das benötigte System und kann dessen Funktionen anschließend als Tasks in DAGs nutzen. Diese modulare Bauweise hält den Kern schlank und erlaubt es, nur das zu laden, was tatsächlich gebraucht wird.
Aus unserer Beratungspraxis decken einige Kategorien den typischen Bedarf datengetriebener Unternehmen besonders gut ab:
Ein Muster verdient besondere Erwähnung, weil es in modernen Datenteams so verbreitet ist: die Arbeitsteilung zwischen Airflow und dbt. Während dbt sich auf die Transformation von Daten innerhalb des Warehouses konzentriert – also darauf, aus Rohdaten saubere, modellierte Tabellen zu machen – übernimmt Airflow die Orchestrierung des Gesamtprozesses: Es sorgt dafür, dass zunächst die Rohdaten geladen werden, dann die dbt-Transformationen starten und schließlich nachgelagerte Schritte wie Berichte oder Exporte folgen. Beide Werkzeuge ergänzen sich, statt zu konkurrieren, und werden in der Praxis oft gemeinsam eingesetzt.
Wenn kein passendes Provider-Package existiert – etwa für ein branchenspezifisches oder selbst entwickeltes System – lässt sich Airflow erweitern. Weil alles in Python geschrieben ist, können Teams eigene Operators und Anbindungen entwickeln oder bestehende anpassen. Das ist ein klarer Vorteil gegenüber geschlossenen Plattformen, verlangt aber Entwicklungskompetenz. Diese Offenheit ist einer der Gründe, warum Airflow auch in sehr individuellen Datenlandschaften funktioniert, in denen fertige Konnektoren an Grenzen stoßen.
Airflow spielt seine Stärken aus, wenn Reife, Verbreitung und ein großes Ökosystem zählen. Für geplante, wiederkehrende Batch-Daten-Pipelines ist es der etablierte Standard, für den es die meisten Anbindungen, die größte Community und den reichsten Erfahrungsschatz gibt. Wer Fachkräfte am Markt findet, auf viele fertige Integrationen zurückgreifen will und einen bewährten, breit unterstützten Weg sucht, ist mit Airflow gut beraten. Auch die freie Wahl der Betriebsform und die daraus folgende Datenhoheit sprechen für Airflow.
Die jüngeren Werkzeuge sind als bewusste Antworten auf empfundene Schwächen älterer Orchestrierung entstanden. Prefect setzt auf ein sehr Python-nahes, flexibles Modell und punktet bei dynamischen Abläufen und moderner Entwickler-Ergonomie. Dagster denkt Orchestrierung von den Daten-Produkten her – es rückt die erzeugten Daten-Assets und deren Herkunft in den Mittelpunkt, was für datenorientierte Teams sehr natürlich sein kann. Temporal verfolgt einen anderen Ansatz und zielt auf die zuverlässige Ausführung langlaufender, zustandsbehafteter Prozesse – weniger auf klassische Daten-Batches, mehr auf robuste Geschäftsabläufe, die auch über lange Zeiträume und Ausfälle hinweg garantiert zu Ende laufen.
In unseren Projekten formulieren wir die Faustregel gern so: Airflow für den bewährten Standard geplanter Daten-Pipelines, Prefect für dynamische und flexible Daten-Flows, Dagster für einen daten- und asset-zentrierten Blick, Temporal für zuverlässige, langlaufende Prozesse jenseits reiner Datenbatches. Die beste Wahl hängt vom konkreten Anwendungsfall und von den vorhandenen Kompetenzen ab – nicht von einer pauschalen Rangfolge.
Grundsätzlich stehen zwei Wege offen: der Eigenbetrieb der Open-Source-Version und der Bezug über einen verwalteten Dienst. Beide haben ihre Berechtigung, und beide bringen sehr unterschiedliche Aufwands- und Kompetenzprofile mit sich. Die richtige Wahl hängt weniger von der Technik als von den vorhandenen Ressourcen und den Anforderungen an Datenhoheit ab.
In vielen produktiven Umgebungen läuft Airflow heute auf Kubernetes, einer Plattform zur Verwaltung von Containern. Der Reiz liegt darin, dass jeder Task als isolierter Container ausgeführt werden kann: Er bringt seine eigenen Abhängigkeiten mit, beeinflusst andere Tasks nicht und kann bei Bedarf horizontal skaliert werden. Das löst elegant das Problem widersprüchlicher Abhängigkeiten und macht die Ressourcennutzung flexibel. Der Preis dafür ist erhebliche Komplexität: Der Betrieb von Kubernetes ist selbst eine anspruchsvolle Disziplin, die entsprechende Kompetenz voraussetzt. Für kleinere Vorhaben ist ein einfacherer Betriebsweg oft angemessener.
Wir betonen in Projekten bewusst, dass der laufende Betrieb der eigentliche Aufwandstreiber ist – nicht die Erstinstallation. Ein Airflow, das produktiv geschäftskritische Datenläufe steuert, braucht Überwachung, Reaktionsfähigkeit bei Störungen, ein durchdachtes Aktualisierungskonzept und Sicherheitspflege. Wer diesen Aufwand unterschätzt, riskiert, dass die Plattform veraltet, unsicher oder unzuverlässig wird. Ein verwalteter Dienst verlagert genau diesen Aufwand zum Anbieter – gegen Entgelt und um den Preis geringerer Kontrolle. Diese Abwägung ist der Kern der Betriebsentscheidung.
Zunächst die gute Nachricht: In datengetriebenen Mittelständlern gibt es zahlreiche Szenarien, in denen Airflow einen echten Unterschied macht. Überall dort, wo bisher verstreute Skripte, manuelle Datenläufe oder unübersichtliche geplante Aufgaben den Alltag prägen, bringt Airflow Ordnung, Nachvollziehbarkeit und Verlässlichkeit. Die folgenden Anwendungsfälle sehen wir in der Praxis am häufigsten.
Hier liegt der entscheidende Punkt für den Mittelstand, den wir nie beschönigen: Airflow verlangt echte technische Kompetenz. Konkret braucht ein produktiver Einsatz mindestens die folgenden Fähigkeiten – entweder im eigenen Team oder über einen Partner:
Diese Anforderungen bedeuten nicht, dass Airflow für den Mittelstand ungeeignet ist – aber sie bedeuten, dass es kein Werkzeug für ein Unternehmen ohne jede technische Ressource ist. Mittelständler mit einem kleinen Data- oder IT-Team, das über die genannten Fähigkeiten verfügt, sind mit Airflow oft hervorragend bedient. Wo diese Kompetenz fehlt und nicht aufgebaut werden soll, ist entweder ein verwalteter Dienst, ein leichtgewichtigeres Werkzeug oder die Zusammenarbeit mit einem erfahrenen Partner der realistischere Weg.
Ein typischer, gesunder Verlauf beginnt klein: ein erster DAG, der einen konkreten, schmerzhaften Prozess ablöst – etwa den bisher manuellen nächtlichen Datenlauf. Aus dem sichtbaren Erfolg wächst Vertrauen, und weitere Pipelines folgen. Wichtig ist, diesen Wildwuchs früh in geordnete Bahnen zu lenken: klare Namenskonventionen, Dokumentation der DAGs, definierte Verantwortlichkeiten und ein sauberer Bereitstellungsprozess. So wird aus einer Sammlung einzelner Pipelines eine tragfähige Orchestrierungs-Plattform, statt einer neuen, schwer wartbaren Komplexität. Wir begleiten diesen Übergang in Projekten bewusst, weil genau hier über den langfristigen Erfolg entschieden wird.
Konkrete Preisangaben nennen wir hier bewusst nicht. Die Open-Source-Software verursacht keine Lizenzkosten, und die Konditionen der verwalteten Dienste ändern sich laufend und variieren stark. Entscheidend ist das Verständnis der Kostenstruktur – die bleibt stabil.
Der wichtigste Grundsatz zur Kostenfrage: Dass Airflow keine Lizenzgebühren kostet, macht es nicht automatisch zur günstigsten Lösung. Die eigentlichen Kosten liegen in der Infrastruktur und im Personal. Ein selbst betriebenes Airflow bindet qualifizierte Mitarbeiter, die die Plattform aufbauen, betreiben und pflegen – und diese Zeit ist real und wertvoll. Ein verwalteter Dienst tauscht diesen Personalaufwand gegen ein laufendes Entgelt. Die ehrliche Gesamtkostenbetrachtung stellt beides gegenüber und bezieht die vorhandenen Kompetenzen mit ein. Wir erstellen diese Rechnung in Projekten standardmäßig, bevor eine Betriebsentscheidung fällt.
Für Mittelständler mit hohen Anforderungen an Datenschutz und Souveränität ist die Möglichkeit des Selbstbetriebs Airflows größte datenschutzrechtliche Stärke. Wird Airflow in einer eigenen oder europäischen Infrastruktur betrieben, bleiben die verarbeiteten Daten unter eigener Kontrolle und verlassen den gewählten Rechtsraum nicht. Das reduziert die Komplexität der datenschutzrechtlichen Bewertung erheblich, weil viele Fragen zu Drittlandtransfers und behördlichen Zugriffsmöglichkeiten gar nicht erst entstehen. Für Unternehmen, die aus Souveränitätsgründen bewusst auf US-Cloud-Dienste verzichten wollen, ist das ein gewichtiges Argument für Airflow.
Wer sich für ein verwaltetes Angebot entscheidet, gibt einen Teil dieser Datenhoheit zugunsten geringeren Betriebsaufwands ab. Das kann eine sinnvolle Abwägung sein – aber sie will bewusst getroffen werden. Zentral ist die Prüfung des Serverstandorts: In welcher Region werden die Daten verarbeitet und gespeichert? Finden Übermittlungen in Drittländer statt? Welche vertraglichen Zusicherungen gibt der Anbieter, und ist ein Auftragsverarbeitungsvertrag geregelt? Diese Fragen sind vor der Nutzung zu klären, insbesondere wenn personenbezogene oder besonders schützenswerte Daten durch die Pipelines fließen. Bei US-basierten Cloud-Diensten bleibt zudem – wie bei allen solchen Angeboten – ein rechtliches Restrisiko hinsichtlich behördlicher Zugriffsmöglichkeiten zu bedenken.
Unsere Empfehlung fällt daher differenziert aus: Für Unternehmen, deren Datenwelt ohnehin in einer bestimmten Cloud liegt und deren Daten unkritisch sind, kann ein verwalteter Dienst die pragmatisch richtige Wahl sein. Für Organisationen mit hohen Souveränitätsanforderungen oder sensiblen Daten spielt der selbst betriebene, quelloffene Airflow seine Stärke aus. Die Entscheidung ist letztlich eine bewusste Abwägung zwischen Bequemlichkeit und Kontrolle – und sollte nie beiläufig getroffen werden.
