Airflow 3 prohibits worker tasks from connecting directly to the metadata database. Workers now execute tasks using the Task SDK, communicating exclusively with a central API server over HTTP.
Security and the principle of least privilege
In Airflow 2, every Celery worker and Kubernetes pod required a direct database connection string to the central metadata database. This architecture had significant security risks:
If an engineer ran custom code with an insecure library, or if an attacker compromised a third-party dependency inside a task, they had read and write access to the entire metadata database. They could inspect connection passwords, modify DAG definitions, or alter other teams' task states. In Airflow 3, the worker only receives a temporary scoped token valid for its assigned task instance.
Eliminating connection exhaustion
Large Airflow deployments with hundreds of concurrent workers frequently overwhelmed PostgreSQL or MySQL with connection spikes. Each worker container opened database connection pools, requiring complex PgBouncer configurations. In Airflow 3, only the airflow api-server connects to the database, pooling queries efficiently and keeping worker processes completely off the database network.
Multi-language tasks and isolation
Decoupling the database allows workers to be lightweight. Tasks import operator definitions from airflow.sdk rather than importing heavy internal core modules that pull in SQLAlchemy and Alembic. Because the interaction protocol is an HTTP REST API, this architectural shift paves the way for running native tasks in languages beyond Python, such as Go or TypeScript, without packaging the Airflow database ORM.