Airflow 3.3.1 is built for scheduled DAGs, not event streams
Airflow 3.3.1 turns a Python definition into a scheduled graph of tasks, then records each run in a metadata database. The scheduler decides when work is ready, an executor sends it to workers, and the web interface shows failures, retries, dependencies, and backfills. That division is useful when a pipeline has to be understood by people other than its first author. A DAG can live beside normal code, go through review, and keep an operational history that cron does not provide.
The boundary matters. Airflow's README 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 passing metadata rather than large datasets. A competent team should walk away if the job is a continuous event loop or if every run invents a new graph. Those shapes fight the product instead of using it.
What happened when we ran it
Our sandbox run at commit d4aa209 installed 151 packages in 205 seconds, occupying 190 MB on disk. The source tree was much larger: 13,808 files, about 1,810,357 lines of source, and 184.6 MB checked out. On the same 3-CPU, 8 GB Debian container, the build completed in 26 seconds. Pip-audit reported 0 known vulnerabilities, which is a clean result for the exact environment we measured.
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. That is all the log tail proves. It does not identify which package supplied the option or why it was absent, so blaming a dependency mismatch would be guesswork. The practical finding is narrower: a successful install and build did not make the repository's default test invocation runnable in our fresh container.
The repository has 52 CI workflow files and a Dockerfile, but no top-level tests directory was detected by our scan. That signal fits Airflow's scale rather than implying it lacks tests: the project is split across core, providers, clients, deployment assets, and tooling. Contributors should follow the documented development environment instead of treating the PyPI quick start as a source-development recipe.
Repeatable installs depend on versioned constraint files
Airflow 3.3.0 supports Python 3.10 through 3.14, while its README gives a constraint URL tied to both the Airflow and Python versions. The maintainers explicitly warn that plain pip install apache-airflow may sometimes fail or create an unusable installation because Airflow sits between a library and an application. Only pip and uv are officially supported for installation. Poetry and pip-tools users are told to adapt the published constraints themselves.
That honesty is useful, but it means dependency resolution is part of operating Airflow. Provider packages add integrations on their own release tracks, and each deployment must pin a known set rather than casually upgrade the whole environment. The 3.3.1 release notes show why: the pandas 3 change affects how DataFrame XComs are named, and every component must be upgraded before pandas 3 reaches any of them. A rollback can strand XCom values written under the newer naming.
Production requires Linux and a real metadata database
PostgreSQL 14 through 18 and MySQL 8.0 or 8.4 appear in the 3.3.0 support matrix. SQLite 3.15.0 or newer is supported for development and tests, but the README says not to use it in production. Native Windows is also outside the supported path. Windows developers need WSL2 or Linux containers, and the project supports Linux distributions for production execution. MariaDB is neither tested nor recommended.
After the database comes the executor, worker capacity, secrets, logs, upgrades, and every connection used by a DAG. Airflow can delegate work to many external systems through providers, which is the main reason to accept this overhead. It should orchestrate large data jobs rather than carry their payloads between tasks. Teams that already run Kubernetes may prefer the official Helm path; smaller installations still need backup and migration discipline around the metadata database.
46,606 stars come with daily maintenance traffic
The repository had 46,606 stars and was pushed on 2026-08-25, the same day we checked it. GitHub reported 1,932 open issues and pull requests combined, and open bug reports were also updated that day. Apache Airflow 3.3.1 was released on 2026-08-12. The dates and active queue point to a heavily maintained project, while the queue size warns that users are buying into a large platform with many providers and upgrade paths.
Documentation is one of Airflow's strongest reasons to choose it. The README states its limits, lists supported databases and platforms, explains constraints, and points to separate guides for the core, provider packages, Docker images, and Helm chart. The release notes include migration consequences instead of a bare changelog. Airflow is the safe pick for an organization that needs a shared batch scheduler and can staff it. For a handful of simple jobs, its 151-package source install and production control plane are more machinery than the problem deserves.