DAG versioning ties each DAG run to the exact snapshot of DAG code and structure that existed when that run was scheduled. It solves a decade-old problem where past pipeline runs showed misleading execution graphs in the UI.
Why Airflow 2 struggled with changes
In Airflow 2, the webserver parsed DAG files from the local filesystem to render task graphs. It had no concept of historical DAG shape. Consider this scenario:
Monday: extract >> transform >> load Tuesday: developer replaces "transform" with "clean >> enrich" Wednesday: on-call engineer inspects Monday's failed run Result: UI displays "clean" and "enrich", which never ran on Monday
If you cleared a failed task from Monday, the worker ran the new Tuesday code against Monday's data interval. This made debugging past incidents confusing and violated data audit requirements for regulated environments.
How Airflow 3 solves it
Airflow 3 records an immutable DAG version in the metadata database every time the DAG structure or parameters change. When a DAG run is created, it records a dag_version_id. The React UI queries the API server for that specific version ID, rendering the true graph that executed at that time.
DAG bundles in production
DAG versioning is supported by DAG bundles. Instead of assuming all workers and webservers share an identical mounted NFS folder, DAG bundles fetch code from named backends like Git repositories or S3 buckets. A worker running a task from last week pulls the exact Git commit hash associated with that run's DAG version.
This change provides clear auditability for financial and compliance teams. You can inspect an ETL run from three months ago and verify the exact SQL statements, operator configurations, and dependencies that produced the report.