Apache Airflow vs Windmill: when each one fits a post-Airflow 2 team
Airflow 3 fits a team whose data engineers already think in Python DAGs and whose operations are built around a scheduler and a metadata database. Airflow 2 reached end of life on April 22, 2026, so an estate still running it gets no fixes and must move to a supported line, and Airflow 3.3.2 is the current release. If your existing DAGs, operators and on-call runbooks are organized around the scheduler, the DAG processor and the metadata database, staying in the Airflow family keeps the most of that knowledge intact. Confirm that your Python versions and your PostgreSQL or MySQL versions fall within the prerequisites for the Airflow 3 line you choose before you plan the upgrade.
Windmill fits a team that wants scripts in several languages, a job-queue model and identity and audit controls from its Enterprise edition. Its API servers and workers pull jobs from a PostgreSQL queue, and scripts can be written in Python, TypeScript, Go, Bash, SQL and other languages, then composed into flows. SAML, SCIM and audit logs are paid Enterprise features, so if SSO and audit evidence are mandatory from day one, price the Enterprise edition into the decision rather than assuming the free Community Edition covers them. Windmill is a different execution model, so treat a move from DAGs as a rebuild of logic, not a file conversion.
The decision turns on three questions. First, who will author and maintain pipelines: Python-first data engineers may prefer DAG code, while mixed-language teams may value Windmill's scripts and flows. Second, which identity and audit controls your auditors and security team require, and whether they must be enforced in the orchestrator itself. Third, how much rebuild effort your existing DAGs represent, counted by the number of pipelines, sensors and custom operators you must reimplement and retest. Ask both vendors and your own platform team to estimate that rebuild against a sample of your real DAGs before committing.
Which platform fits which team scenario
This table maps common team situations to the platform that fits them better, based on authoring model, infrastructure footprint, and what sits behind Windmill's paid Enterprise Edition. Read each row for the condition that decides the choice, and use the scenarios as a checklist against your own estate.
| Scenario | Better fit | Why |
|---|---|---|
| Python data engineering team with many existing DAGs | Apache Airflow | Existing DAGs, operators and provider packages carry over with far less rewriting than moving to a different authoring model. Airflow wins when the DAG estate is the main asset to preserve. |
| Platform team with mixed-language automation in Python, TypeScript, Bash and SQL | Windmill | Windmill scripts can be written in many languages and composed into flows, so one tool can host automation owned by several teams. Airflow centers on Python DAGs, so other languages usually run through operators or external tooling. |
| Regulated team needing SSO, SCIM and audit logs on day one | Windmill | Windmill Enterprise lists SAML, SCIM and audit logs as paid features, so the requirement maps directly to a licensed edition. Confirm the controls you need against the current pricing page before committing. |
| Team with an existing PostgreSQL estate but no Airflow metadata database | Windmill | Windmill's queue lives in PostgreSQL and supports external managed PostgreSQL services. Airflow also supports PostgreSQL, but it adds a scheduler, DAG processor and API server that each need operating and monitoring. |
| Team that must keep Airflow 2 DAGs running for a short migration window | Apache Airflow | Airflow 2 is past end of life, so staying on it means no fixes. Keeping DAGs running safely means moving to Airflow 3 first, which is a version step to plan rather than a window to rely on. |
How Airflow 3 and Windmill are built, and what each means for operations
Airflow 3 splits work across a scheduler, a DAG processor, an API server and a metadata database. Windmill runs stateless API servers and workers that pull jobs from PostgreSQL. The cards below trace each design choice to what you must back up, what scales out, and what your team operates.
Airflow's component split
Airflow 3 runs a scheduler, DAG processor, API server, metadata database and executors as separate parts. Each one has its own process to monitor and restart, and the metadata database holds DAG run state, so it is the component you must back up and restore first. Ask your team which executor you will run, because the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0.
Multiple schedulers and row-level locks
Airflow can run more than one scheduler at once for performance and resiliency, coordinating through database row-level locks. That makes the database the coordination point, so scheduler scale-out is limited by how well your metadata database handles lock contention. Plan database sizing and monitoring before adding scheduler replicas, and test failover in a staging environment.
Airflow database and runtime prerequisites
Airflow 3.3.2 supports PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases for the metadata database, and it does not support MariaDB. It requires Python 3.10 to 3.14 and recommends at least 4 GB of RAM. SQLite is for testing only, so a production Airflow estate starts with a managed or self-run PostgreSQL instance inside your own network.
Windmill's stateless servers and queue
Windmill's backend is written in Rust, with stateless API servers and workers that pull jobs from a PostgreSQL queue. Because the servers hold no job state, you can add or replace them without moving data, but the PostgreSQL database becomes the single source of truth for queued and completed jobs. Confirm your backup, point-in-time recovery and failover plan for that database before going live.
Windmill's nsjail sandboxing
Windmill runs jobs in sandboxes built with nsjail. Your security team should review how that isolation maps to the scripts your teams write, especially any script that calls internal networks or handles credentials. Pair sandboxing with the external secret backends in Enterprise Edition, such as Vault or AWS Secrets Manager, if you do not want secrets stored in Windmill itself.
Worker sizing and external databases
Windmill's README suggests one worker per vCPU with 1 to 2 GB of RAM, a rule of thumb you should validate with your own job mix. Windmill documents external PostgreSQL options such as AWS RDS, GCP Cloud SQL and Azure, which moves backup and patching to your cloud provider but not your configuration. Ask the vendor or your platform team to confirm how worker counts change under your peak schedule.
Capability differences that decide the shortlist
This table sets Apache Airflow 3 against Windmill on the capabilities that usually decide a shortlist. Where the supplied facts do not establish a capability, the cell says so and names what to confirm. Read the Windmill rows that mention Enterprise as paid features, since the Community Edition does not include them.
| Capability | Apache Airflow | Windmill |
|---|---|---|
| License | Apache-2.0. The project itself offers no paid edition. | AGPLv3 and Apache-2.0 for source built without the enterprise flag. Prebuilt images include proprietary code, free for internal use. |
| Authoring languages | Python DAGs. | Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more, composable into flows. |
| Local testing approach | Not covered in the supplied facts. Confirm the local DAG testing workflow for your Airflow version before committing. | Not covered in the supplied facts. Confirm how scripts and flows run locally and in CI during a proof of concept. |
| Scheduling, backfills and workers | Scheduler, with multiple schedulers supported through database row-level locks. Executors include Local, Celery, Kubernetes, Edge, AWS Batch and ECS. Confirm backfill behavior for your DAGs. | Stateless API servers and workers pull jobs from a PostgreSQL queue. Backfill support is not in the supplied facts; confirm it. |
| Metadata or job store and supported databases | Metadata database on PostgreSQL 14 to 18 or MySQL 8.0 and 8.4. MariaDB is unsupported, and SQLite is for testing only. | PostgreSQL job queue. External PostgreSQL such as AWS RDS, GCP Cloud SQL or Azure is supported. |
| SSO (SAML and SCIM), audit logs | Auth manager is documented, but SAML, SCIM and audit log support are not in the supplied facts. Confirm with the auth manager you plan to use. | Enterprise adds SAML, SCIM and audit logs. These are paid features, so confirm them against your licence before a decision. |
| External secret backends and full Git sync | Not in the supplied facts. Confirm secrets backend options and Git-based DAG sync for your deployment method. | Enterprise adds external secret backends such as Vault and AWS Secrets Manager, plus full Git sync. |
| Autoscaling, Prometheus and OpenTelemetry | Not in the supplied facts. Confirm autoscaling behavior for your executor and metrics export options. | Enterprise adds autoscaling and Prometheus and OpenTelemetry support. |
| Self-hosting methods | Official Helm chart, production Docker images or a PyPI install. Confirm which one your team can operate. | Docker Compose or Kubernetes Helm charts, with external PostgreSQL supported. |
What is free, what is paid, and the license terms behind each
Apache Airflow is an Apache Software Foundation project released under the Apache License 2.0 (Apache-2.0). The project does not sell a paid edition, so the software license carries no fee, and your cost sits in infrastructure, staff time and any support contract you buy from a third party. For most teams the licensing question centers on version. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026. Limited maintenance covered only security and critical bug fixes, and end of life means no fixes or support at all.
- Apache-2.0 terms: The license permits use and modification subject to its conditions, with no license fee payable to the project.
- No project-issued paid tier: Any paid support or managed hosting comes from a separate provider, and that provider sets its price.
- Airflow 2 past end of life: Since April 22, 2026, Airflow 2 receives no fixes, so an Airflow 2 estate carries unpatched exposure for every new vulnerability disclosed.
- Current line: Airflow 3.3.2 is the current release, and it is the baseline against which migration effort should be priced.
Confirm with your Airflow provider or internal team which Airflow 2 patch level you run and whether any vendor will patch it after April 22, 2026.
Windmill's license depends on how you build it and how you deliver it. Source compiled without the enterprise feature flag is licensed under AGPLv3 and Apache-2.0. Prebuilt Community Edition images also include proprietary code, which is free for internal use. The terms that decide your position are therefore about who uses the running software and whether you offer it to anyone outside your organization.
- Source build without the enterprise flag: The code falls under AGPLv3 and Apache-2.0, and those license terms govern your build.
- Prebuilt Community images: The official images contain proprietary code, so the image is governed by Windmill's terms rather than by open-source terms alone.
- Internal use: Running the prebuilt Community Edition inside your own organization is free under those terms.
- Managed services and resale: Offering Windmill as a hosted service or reselling it requires a commercial license from Windmill.
Ask counsel to map each planned use, such as internal automation, a customer-facing product or a hosted service for clients, to the license that applies, and obtain Windmill's answer in writing before you build an offering on it.
The self-hosted Community Edition is free and lists unlimited executions on the pricing page as of October 2026. Its limits are structural rather than volume based: it caps workspaces at 3, users at 50 and groups at 4. Those caps shape how you organize Windmill from the first day, so they matter more than the absence of a license fee. The Enterprise features that handle identity and audit, such as SAML, SCIM and audit logs, sit outside this tier.
- Unlimited executions: Run volume does not trigger a fee on the Community Edition price list, so job count alone is not a cost driver there.
- Three workspaces: This limit matters if you separate development, test and production, or give each business unit its own workspace.
- Fifty users and four groups: Teams that grow beyond these counts will hit the ceiling and need to move to a paid tier.
- No Enterprise identity or audit features: Single sign-on through SAML, SCIM provisioning and audit logs are not part of this tier.
Illustratively, a company that wants one workspace for each of four departments would exceed the three-workspace limit before it reaches 50 users. Confirm the current limits on the pricing page and in writing with Windmill before you design your workspace layout.
Windmill's self-hosted Enterprise Edition starts at $120 per month, according to its pricing page as of October 2026. The starting figure is a floor, not a full estimate, because the pricing is built from per-user components and compute units. Developers are priced at $20 per month each, operators at $10 per month each, and compute is billed separately. The cost recurs monthly, so headcount and compute growth both raise the bill over time.
- Starting price: Enterprise begins at $120 per month, stated on the pricing page as of October 2026.
- Developer seats: Each developer seat is listed at $20 per month.
- Operator seats: Each operator seat is listed at $10 per month.
- Compute units: Compute is metered in units, so ask how usage is measured and whether autoscaling increases the count.
- Enterprise features: SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, full Git sync, autoscaling, and Prometheus and OpenTelemetry support are included.
Ask for a written quote that shows the developer and operator counts, the compute unit assumptions, whether the starting fee already covers any seats, and the renewal and adjustment terms.
What drives the running cost of each platform
Running cost for both platforms comes from the same few places: the services you host, the people who operate them, the paid edition features you need, and the upgrade work that comes back on a schedule. The cards below separate what you pay once from what recurs, so you can ask both vendors and implementation partners for the same line items.
Airflow service footprint
A self-hosted Airflow 3 estate runs a scheduler, a DAG processor, an API server, a metadata database and executor workers, and the Airflow prerequisites recommend at least 4 GB of RAM. Production guidance points to PostgreSQL or MySQL rather than SQLite, so the database is a managed or self-run service you pay for and back up. Ask who operates each component and what the database and worker capacity costs at your DAG volume.
Windmill service footprint
Windmill runs stateless API servers and workers that pull jobs from a PostgreSQL queue, so PostgreSQL becomes the central service to size, back up and patch. The README's rule of thumb is one worker per vCPU with 1 to 2 GB of RAM per worker. Ask how many workers your job mix needs and whether your PostgreSQL service is the same one your other platforms already use.
Skills and on-call coverage
Airflow estates are usually operated by Python-fluent data engineers, while a mixed-language team may write Windmill scripts in TypeScript, Go, SQL or Bash. Fewer specialist skills can lower the cost of on-call and handover, but only if the team can debug jobs in each language. Ask who will own the scheduler and worker incidents, and how many people can answer a page without a specialist.
Windmill Enterprise seats and compute
The self-hosted Windmill Enterprise Edition starts at $120 per month, with developers at $20 per month each, operators at $10 per month each and compute units billed on top, according to Windmill's pricing page as of October 2026. SAML and SCIM, audit logs and external secret backends sit in this paid tier. Ask for the seat split, the compute unit assumptions and whether a quote covers your identity and audit requirements.
Airflow major version upgrades
Airflow 2 reached end of life on April 22, 2026, so an Airflow 2 estate has no fixes unless it moves to a supported line. Each major line brings DAG and executor changes, and the hybrid executors were removed in Airflow 3.0.0. Plan recurring patch and upgrade work for Airflow 3, and ask a partner to include upgrade testing, not only the first migration, in the written scope.
One-time migration and identity work
Rewriting DAGs, testing migrated jobs side by side, and connecting SSO and audit trails are one-time costs for either platform. Windmill's Enterprise identity and audit features may reduce integration work if you need them, while Airflow relies on the auth manager you configure. Ask for the migration inventory, the test plan and the identity integration steps as separate line items in a fixed-scope quote.
How to move from Airflow 2 to Windmill, or to Airflow 3, in order
This sequence takes a team from an end-of-life Airflow 2 estate to a working replacement, whether that replacement is Windmill or Airflow 3. Each step ends with a check you can verify before the next one starts.
Inventory DAGs, operators, connections and variables
Engineers who own the pipelines list every DAG, the custom operators and hooks it imports, the connections and variables it reads, and the schedules and sensors that trigger it. Include the alerting callbacks and any Airflow plugins, since these are easy to miss. The step is done when the inventory names an owner, a schedule and a downstream consumer for each DAG, and when every secret is traced to the store that holds it today.
Decide which DAGs to retire, rewrite or keep
Platform owners and pipeline owners sort the inventory into three groups: pipelines to retire because nothing consumes them, pipelines to rewrite because they depend on Airflow-specific operators or features, and pipelines to keep on Airflow 3 because they are too costly to move in the same window. Record the decision and the reason for each DAG in a shared register. The step is done when the register is approved and every DAG has exactly one of the three outcomes.
Build the target platform in a non-production environment
The platform team deploys the target in a non-production environment inside your own infrastructure. For Windmill, this means its API servers and workers, a PostgreSQL database (external or bundled, per the self-hosting options in its repository) and SSO and audit settings if you need them on the Enterprise tier. For Airflow 3, it means the scheduler, DAG processor, API server and a PostgreSQL or MySQL metadata database, with the auth manager you choose. Confirm the supported database versions against the vendor documentation before you provision. The step is done when a test job runs end to end and an identity login and an audit record are both confirmed.
Re-create schedules and secrets through the external backend
Schedules and secrets are the two items that carry over in different ways. Re-create each schedule in the new platform and check the cron expression, timezone and catch-up behavior against the old definition, since the old scheduler and the new one will not produce identical runs. Move secrets into an external secret backend that both platforms can reach during the transition, rather than copying values into configuration files. The step is done when each re-created schedule has been compared with its Airflow 2 definition and no credential is stored in plain text on the new platform.
Rewrite and run a representative pipeline set in parallel
Pipeline engineers rewrite a representative set of DAGs, chosen to cover each operator type, failure pattern and data destination in the estate. Each rewritten job runs alongside its Airflow original, writing to a separate target, so outputs can be compared row for row. Expect most of the effort here, since DAG code, custom operators and alerting all have to be rebuilt on the new platform. The step is done when parallel outputs match for an agreed set of runs and every alert path fires in a test.
Cut over in batches with a tested rollback plan
Move the retired-and-rewritten DAGs in batches, starting with pipelines that have the lowest downstream impact. Before each batch, write down the rollback steps, including how to pause the new schedule and resume the Airflow original, and rehearse them in the non-production environment. Keep the old scheduler running for the kept DAGs until the batch is confirmed. The step is done when each batch has a signed-off cutover record and a rollback that has been rehearsed at least once.
Decommission the old scheduler and its metadata database
Once every DAG has a verified outcome, the platform team stops the old scheduler, archives the Airflow metadata database according to your retention policy, and removes its connections and secrets. Keep a read-only copy of run history if audit or compliance teams require it. Confirm the Airflow 2 instance is gone from monitoring and backup jobs. The step is done when the archive is verified and the decommissioning record lists every system, credential and job removed.
What buyers ask before choosing or hiring help with Airflow or Windmill
How much effort does migrating from Airflow 2 to Windmill take?
The effort depends mainly on how many DAGs you run, how much logic sits in custom operators and plugins, and how tightly your pipelines depend on Airflow's metadata database, connections and variables. Airflow 2 reached end of life on April 22, 2026, so it gets no fixes, which means the move is now a question of timing and scope rather than whether to act. Windmill scripts can be written in Python, so Python tasks port more directly than tasks written against Airflow's operator classes, which need to be rewritten as scripts or flows. Ask any provider for an inventory of DAGs, operators, connections and schedules, then a written, scope-based quote that separates the rewrite from testing and cutover.
Can we self-host Windmill with Docker Compose or Helm ourselves?
Yes, the Windmill repository documents self-hosting with Docker Compose and Kubernetes Helm charts, and it supports external PostgreSQL services such as AWS RDS, GCP Cloud SQL and Azure. Your team needs to operate PostgreSQL, the API servers and the workers, size the workers (the README suggests one worker per vCPU with 1 to 2 GB of RAM as a rule of thumb), and handle upgrades. Windmill's backend runs jobs in sandboxes using nsjail, so confirm that your hosts and container runtime allow that configuration. A team without Kubernetes or PostgreSQL operations experience should plan for that skill gap before committing to a self-managed rollout.
Are SSO and audit logs free in Windmill?
No. According to Windmill's pricing page, SAML and SCIM, audit logs, external secret backends, full Git sync, autoscaling, and Prometheus and OpenTelemetry support sit in the self-hosted Enterprise Edition, which starts at $120 per month. The free Community Edition has unlimited executions but is limited to 3 workspaces, 50 users and 4 groups, as of October 2026. Confirm current pricing and the exact feature list on the pricing page before budgeting, because both change. Also ask how the Enterprise license terms apply to your deployment model.
Does Apache Airflow have a paid edition?
No. Apache Airflow is an Apache Software Foundation project released under the Apache License 2.0, and the project itself offers no paid edition. Costs come from the infrastructure you run, including the scheduler, DAG processor, API server, metadata database and workers, plus the engineering time to operate and upgrade them. Managed Airflow services from third parties are separate products with their own pricing, so compare those against your own hosting cost and effort.
What does a rebuild of existing DAGs actually require?
A rebuild needs an inventory of every DAG, its schedule, dependencies, sensors, connections and custom code, followed by a decision on which pipelines to rewrite, which to retire and which to run in parallel during cutover. Airflow 3 changed several behaviors, so compare your DAGs against the upgrade guidance before assuming they will run unchanged. Test each migrated flow against the same data inputs and compare outputs, retries and failure alerts. Ask the provider to state which of these steps are included in the fixed scope and which depend on your data access and approvals.
Which parts of the migration does DeployOpen do, and which do we keep?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Typical work includes platform setup, rebuilding selected pipelines, integrating identity and secrets, and preparing documentation and runbooks. Your team keeps decisions about data ownership, business logic sign-off, access approvals and production change control. Ongoing support, upgrades and continuous testing are available as retainers. Request a written, scope-based quote that lists each deliverable and who owns it.
Can our team run the platform without outside help after go-live?
It can, if your team has PostgreSQL operations skills, Linux and container or Kubernetes experience, and someone who owns upgrades and monitoring. Windmill's API servers and workers are stateless and pull jobs from a PostgreSQL queue, so the operational surface is smaller than a scheduler-plus-metadata-database design, but the database and worker capacity still need ownership. For Airflow, plan for the scheduler, metadata database and executor choice, and confirm the supported Python and PostgreSQL versions for your target release. Ask any provider to document the runbook it would hand over.
What should we confirm about Windmill licensing before we deploy?
Confirm the license that applies to the build you deploy. Windmill's repository states that source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, but prebuilt Community Edition images include proprietary code that is free for internal use. Managed services or reselling require a commercial license. Ask your legal team to review these terms against how you plan to use the platform, including whether any users or business units outside your organization will access it.
How DeployOpen helps choose, implement or migrate without favoring either platform
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Apache Airflow vs Windmill, we start by testing which platform fits your workflows, team skills and compliance evidence, then carry out the chosen path or an Airflow 2 migration in writing.
How we scope
- Inventory existing Airflow 2 DAGs, operators, connections and schedules before recommending either platform.
- Confirm which Airflow 3 or Windmill components run in your own cloud, data center or air-gapped network.
- Agree deliverables, timelines and exclusions in writing before any work starts, as most engagements are fixed-scope.
- Ask us to state how Windmill Enterprise features such as SAML, SCIM and audit logs map to your requirements.
How we build
- Deploy the chosen platform with PostgreSQL or MySQL metadata storage, not SQLite, and document each component.
- Port or rewrite pipelines, then test them locally and in a staging environment before any production cutover.
- Configure secrets, identity integration, logging and backups to match your own security baseline.
- Run security testing against the deployed orchestrator, its APIs and its connections to data stores.
How we hand over
- Deliver architecture, runbooks, upgrade procedures and configuration records your team can operate without us.
- Walk your engineers through authoring, local testing and deployment workflows on the chosen platform.
- Document the evidence your compliance assessors may ask for, while noting that auditors issue any attestation.
- Record open items and licensing conditions so your procurement and legal teams can confirm them directly.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Plan version upgrades against each platform's published release cadence and support windows.
- Review Windmill Community Edition limits and Enterprise terms with you as your team and workspaces grow.
- Quotes follow from the written scope, and we do not publish a price list, so ask for line items.
