Airflow 3 shifts the platform from a database-coupled monolith to an API-driven architecture. Released in April 2025, it addresses long-standing operational pain points around worker security, DAG code versioning, and event-driven orchestration.
Decoupled task execution
In Airflow 2, every worker held direct database credentials and ran SQLAlchemy queries against the metadata database. Airflow 3 replaces this with the Task Execution API. Workers now communicate strictly with a central execution API server, running through airflow api-server. This isolates database credentials, eliminates connection pool exhaustion caused by rogue worker tasks, and allows lightweight execution environments.
DAG versioning and bundles
Past Airflow versions had a serious limitation: the web UI always rendered whatever DAG file was currently on disk. If you changed a pipeline on Wednesday, inspecting Monday's run displayed the Wednesday code graph. Airflow 3 introduces native DAG versioning backed by DAG bundles (like Git repositories or object storage). Each run is permanently pinned to the exact code revision that scheduled it, making historical audits and triage reliable.
New UI and first-class backfills
The legacy Flask-AppBuilder web interface is replaced by a React-based frontend served by the API server. Backfills are no longer fire-and-forget CLI scripts that run outside standard visibility. They are first-class, scheduler-managed operations that appear in the UI with their own state tracking and pause controls.
Assets and execution components
Airflow Datasets are renamed to Assets and expanded. They support the @asset decorator and asset watchers for external event sources like Kafka topics and cloud queues. At the infrastructure level, the DAG processor runs as its own standalone component by default, and the Edge Executor enables remote workers in air-gapped or on-premises networks to pull work over HTTPS.