Airflow 3.3.2 is for scheduled graphs that stay recognizable
Airflow 3.3.2 turns a Python definition into a scheduled graph of tasks, then records each run in a metadata database. Its scheduler decides when work is ready, an executor sends it to workers, and the web interface shows dependencies, failures, retries, and backfills. That split pays off when a pipeline must be understood by people other than its first author. A DAG can live beside ordinary code, pass through review, and retain an operational history that cron does not provide.
The boundary is unusually clear for a project with 14,427 files. Airflow says it works best when a DAG is mostly static and changes slowly between runs. It is not a streaming engine, even if teams use it to pull records from streams in batches. Tasks should be idempotent, and XCom is for metadata rather than large datasets. If every run invents a new graph or moves a large payload between steps, you are working against the design.
What happened when we ran it
Our sandbox run at commit 413ae46 installed 152 packages in 94 seconds and occupied 196 MB on disk. The checkout itself was 193 MB, with about 1,976,757 lines of source. On the same unprivileged Debian container with 3 CPUs and 8 GB of RAM, the build completed in 21 seconds. Pip-audit reported 0 known vulnerabilities for the exact environment we measured. Those are repository mechanics, not scheduler throughput or task performance.
The test step failed after 7 seconds with exit 4. Pytest rejected --asyncio-mode=strict, naming /work/repo/pyproject.toml as its configuration file and /work/repo as the root. The log tail does not identify why that option was unavailable, so blaming a missing plugin or a dependency mismatch would be guesswork. The useful finding is narrower: a successful 94-second install and 21-second build did not make the configured test command runnable in our fresh container.
Our scan counted 56 CI workflow files and found a Dockerfile, but no top-level tests directory. That last signal does not mean a 1,976,757-line repository has no tests. Airflow spreads core code, providers, clients, deployment assets, and development tooling across a large source tree. A contributor should use the documented development environment instead of assuming the PyPI installation path is also the source-development path.
Airflow 3.3.2 expects a versioned constraint file
The 3.3.2 README warns that plain pip install apache-airflow may sometimes fail or produce an unusable installation. Airflow keeps library dependencies open in pyproject.toml, then publishes known-working constraint files for each Airflow and Python version. Only pip and uv are officially supported. Poetry and pip-tools users are told to convert the constraints to their own workflow, which puts compatibility work back on the adopting team.
Our 152-package install succeeded, but production begins after package resolution. You still choose a metadata database and executor, configure logs, store credentials, and install providers for the systems each DAG calls. Core Airflow and provider packages have separate release tracks. That flexibility is why Airflow can coordinate a broad data estate, and it is also why casual upgrades are a poor operating habit. Pin the environment, test DAGs and migrations, then move every component together.
Linux and a real database are production requirements
Airflow 3.3.2 supports Python 3.10 through 3.14. Its matrix lists PostgreSQL 14 through 18 and MySQL 8.0 or 8.4, while MariaDB is not recommended. SQLite 3.15.0 or newer is acceptable for local work and tests, but the README explicitly rules it out for production. Native Windows is unsupported; developers need WSL2 or Linux containers, and production execution is supported on Linux distributions.
The 3-CPU, 8 GB sandbox did not exercise a scheduler, workers, a production database, or an external service. Those parts carry the real operating cost: database backups and migrations, task logs, secrets, worker capacity, and credentials for every destination. Airflow is most useful as the coordinator of large jobs running elsewhere. Treating XCom as a data bus or the metadata database as disposable storage turns the control plane into the bottleneck.
The October 3 push shows active work and a large queue
GitHub showed 47,036 stars and a push on 2026-10-03. Its combined counter held 1,829 open issues and pull requests; separate searches returned 1,027 issues and 802 pull requests. Apache Airflow 3.3.2 shipped on 2026-09-17. Those dates rule out a dormant-project concern, while the queue size makes the tradeoff plain: this is a large platform with many integrations, release paths, and user environments to support.
The 3.3.2 release also changed authorization behavior around backfill IDs and explicit credentials, alongside a long list of scheduler, API, migration, and interface fixes. Mature does not mean motionless. Teams need to read release notes, test upgrades against their own providers, and plan database changes. Airflow's documentation earns trust here because it states platform limits, explains constraints, and separates guides for the core, provider packages, containers, and Helm deployments.
Choose Airflow when 152 packages buy shared operations
Airflow earns its place when several teams need one visible record of scheduled work, failed runs, retries, and backfills. The 94-second install and 21-second build show that the code can be assembled quickly in a clean container, while the test stop and production requirements show why adoption is an operations decision. For a few jobs, Prefect or plain scheduling may demand less care. For data assets, Dagster offers a different center of gravity. Kubernetes-first shops should compare Argo Workflows before adding another control plane.