Apache Airflow cost of ownership and editions

Overview

Apache Airflow is released under the Apache License 2.0 (SPDX identifier Apache-2.0) by the Apache Software Foundation, and the project itself offers no paid edition. The software license costs nothing. What you pay for is everything around it: compute for the scheduler, API server, DAG processor and workers, a production-grade metadata database, storage and backups, the staff who build and operate the platform, and any support contract you choose to buy from a commercial provider. Build work is largely one-time, while operations, patching and upgrades recur.

A cost review is worth running at four points: when you first choose a platform for scheduled pipelines, when a managed Airflow offer reaches your desk, when an Airflow 2 estate needs an end-of-life plan (Airflow 2 reached end of life on April 22, 2026 and receives no fixes), and when a growth forecast changes the number of DAGs, tasks or teams. Each trigger moves a different input, such as executor capacity, database sizing or the amount of DAG code that needs rework.

A partner helps most when those inputs are unclear, such as the executor choice, the number of schedulers you need for resilience, or how much migration work sits in your existing DAGs. Most DeployOpen engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, and a quote follows from that written scope. Ask for the total split into build, run and upgrade costs so the recurring share is visible to your finance team.

Managed Airflow services and vendor-built distributions are separate products. This page does not cover their prices, included features, support levels or terms, and those can change, so confirm them directly with each vendor in writing. When you compare, match the same workload, supported Airflow version, metadata database, executor and support hours on both sides before placing the two totals side by side.

What the cost assessment includes

A cost of ownership review turns the Airflow decision into a model that finance and platform leaders can check line by line. Each item below is a component of the work, and each one produces a file you keep.

Target workload inventory

DeployOpen starts by listing the Airflow environments in scope, such as development, test and production, with DAG counts, schedules, executor type, metadata database and the providers each DAG depends on. Ask whether the inventory includes the planned Airflow 3 components, such as the API server and the DAG processor, because each runs as a separate service with its own capacity.

Multi-year cost model

The model covers the planning horizon you choose, five years by default. It separates one-time costs, such as migration, initial build and hardening, from recurring costs, such as compute, storage, backups, upgrades and staff time. Each line names who pays for it, what drives it up or down and the unit it is measured in, so you can change one input and see the effect.

Self-hosted and managed comparison

Self-hosted Airflow carries no license fee, so the comparison turns on infrastructure, people and support against a managed Airflow service's subscription. The review lists what each option includes, such as metadata database operations, scheduler and worker scaling, upgrades and identity integration, and asks each provider to confirm those boundaries in writing.

Written assumption register

Every input the model depends on is recorded with its source and owner. That includes engineering rates, the cloud pricing basis, expected DAG growth, executor capacity, support hours and the Airflow release line assumed. Finance and platform leads review the register before the numbers are used, because one unexamined assumption, such as staying on Airflow 2 after its end of life, can change the result.

Deliverables handed over

The final package contains a cost model workbook, a component inventory, the assumption register, a decision memo that states the recommended option and its main risks, and a list of questions for each vendor or partner quote. Each file is written so your team can reuse it when the scope or the managed-service quotes change.

Planning tool, not a quote

The model is a planning tool. It is not an audit, a budget commitment or a price quote from DeployOpen, and it does not replace independent financial review. Figures change with vendor pricing, cloud rates and staffing decisions, so confirm current prices with each provider and with DeployOpen's written scope before you commit budget.

What drives the cost

Each row names a driver that changes self-hosting cost or effort for Airflow, why it moves the total, and what keeps it contained.

Driver	Why it moves cost	What keeps it down
DAG and task volume	More DAGs and tasks mean more scheduler load, metadata writes, logs and worker time, and more code to test and maintain.	Standardize DAG authoring, group related pipelines, and prune retired DAGs before sizing infrastructure.
Peak concurrency	Peak simultaneous running tasks set worker capacity, so sizing for the busiest window costs more than the average.	Measure real peaks, cap concurrency per pool and queue, and schedule heavy jobs outside busy windows.
Executor choice	LocalExecutor, CeleryExecutor, KubernetesExecutor, EdgeExecutor and AWS Batch or ECS differ in worker infrastructure, broker needs and operating skills.	Start with the simplest executor that meets workload needs, and confirm supported combinations in the executor documentation.
Schedulers and API servers	Running more than one scheduler adds resilience and throughput but also compute, database connections and monitoring. In Airflow 3 the API server and DAG processor run as separate components.	Add schedulers only when load or availability requires it, and size API servers and DAG processors from measured use.
Metadata database	PostgreSQL 14 to 18 or MySQL 8.0, 8.4 and Innovation releases are supported for production. Database sizing, backups, failover and upgrades carry recurring cost. MariaDB and SQLite are not suitable for production.	Use a database your organization already operates, confirm the version in the prerequisites, and reuse existing backup and failover tooling.
Hosting and environments	Kubernetes (versions 1.30 to 1.35 per the prerequisites) or VMs each carry platform labor. Every extra environment such as test, staging or disaster recovery repeats infrastructure and upgrade work.	Use one shared platform team and infrastructure-as-code, and keep non-production environments small but structurally identical.
Secrets and identity integration	Connecting a secrets backend and an identity provider adds design, configuration and testing. Airflow 3 allows one auth manager at a time, so changes to identity mapping affect every user.	Decide the auth manager and secrets backend early, map groups to roles once, and reuse the identity provider already in place.
Compliance evidence needs	Assessors may ask for access reviews, change records, backup restore tests and audit logs. Producing and retaining this evidence is recurring work that grows with each control in scope.	Agree the control list before build, automate log and configuration collection, and confirm evidence requirements with your auditor.
Airflow 2 to 3 starting point	Airflow 2 reached end of life on April 22, 2026, and upgrading requires Airflow 2.7 or later. Moving existing DAGs to Airflow 3 adds code changes, testing and cutover work.	Start new work on Airflow 3, and if migrating, move to the latest 2.x first and check DAG code with the Ruff AIR rules.

How the cost review runs

The review moves from an inventory of today's workloads to a costed comparison of architecture options and managed services, ending in a decision memo the client can take to budget approval.

Inventory workloads and components
The client's data and platform team lists every DAG, its schedule, upstream and downstream systems, runtime needs, and any scheduler, cron job or orchestrator it would replace. DeployOpen maps these to Airflow components: scheduler, API server, DAG processor, metadata database, triggerer and workers. The step closes with a component inventory signed off by the client. Timing depends on how much workload data the client can provide and how many options they want modeled.
Model architecture options side by side
Each option sets the executor (LocalExecutor, CeleryExecutor, KubernetesExecutor, EdgeExecutor, or the AWS Batch and ECS executors), the metadata database, the deployment target and the number of environments. The database options are PostgreSQL or MySQL, since SQLite is not for production and MariaDB is not supported. The output is a comparison sheet listing the components each option needs, with supported versions confirmed against the current prerequisites.
Build the one-time and recurring cost model
One-time lines cover design, build, data or DAG migration and initial testing. Recurring lines cover compute for the scheduler and workers, the database, storage, backups, monitoring, staff time to operate and upgrade, and any support agreement. The Apache-2.0 software has no license fee, so the model has no license line. For each line the model names who pays: the client's cloud account, the client's staff, or a fixed-scope DeployOpen fee. The output is a model with stated assumptions.
Compare managed services on supplied quotes
The client collects written quotes from the managed Airflow providers it is considering and shares them with DeployOpen. Each quote is restated on the same basis as the self-hosted model: the same workloads, environments, term, support level, data location and exit terms. DeployOpen does not obtain or estimate vendor prices. The output is a side-by-side comparison that shows where each quote's assumptions differ from the client's own.
Write the decision memo and open questions
The memo summarizes the workload inventory, the options modeled, the cost model and the managed-service comparison, then states the trade-offs in plain terms. It ends with open questions, each assigned an owner and the source that answers it, such as a vendor confirmation, a security review or a data residency decision. DeployOpen recommends an option only if the client asks for one.

Recurring costs after go-live

This table lists the costs that recur over a multi-year Airflow run, showing who pays for each line under self-hosting and under a managed service, and whether the cost is one-time or recurring.

Cost line	Self-hosted: who pays	Managed service: who pays	One-time or recurring
Compute for scheduler, API server, DAG processor, workers and triggerers	Your cloud or data center account, billed by your infrastructure team	Included in the service fee; confirm which components are metered	Recurring, grows with DAG count and task concurrency
Metadata database and backups	Your team runs PostgreSQL or MySQL and pays for backup storage and retention	Provider fee, often tied to instance size; confirm backup retention and restore testing	Recurring, grows with run history and retention settings
Logging and monitoring	Your log storage, metrics stack and alert tooling	Provider tiers may include logs; confirm export options and retention limits	Recurring, grows with log volume
Container registry and image patching	Your registry and a rebuild pipeline for the official image and custom images	Provider manages base images; you still own custom image builds	Recurring, driven by patch cadence
DAG delivery tooling	Git hosting, CI runners and sync tooling your team operates	Often included; custom CI pipelines and code review remain your cost	Recurring, driven by team size and release frequency
Upgrades to stay on a supported release	Internal staff or a partner under a fixed-scope upgrade. Airflow 2 reached end of life on April 22, 2026.	Provider may apply platform upgrades; DAG and custom code testing stays with you	Recurring at each minor or major release cycle
Provider package updates	Your team tests and pins provider versions against your DAGs	Same testing work applies to custom code that depends on providers	Recurring, driven by provider release cadence
Internal platform staff time	On-call, access reviews, incident response and DAG owner support	Lower operating effort, but DAG owner support and access reviews remain	Recurring, usually the largest line over several years
Support or retainer contract	Optional: vendor support or a partner retainer you contract separately	Included in the subscription tier; confirm response scope and exclusions	Recurring, optional, priced in your agreement

Where cost models go wrong

Six errors make a self-hosted Airflow cost model too low. Each card names the error and the prevention step the model should include.

Software cost and people time

Apache Airflow is licensed under Apache-2.0 with no paid edition from the project, so the license line is zero. The larger costs are the engineering hours to plan, build, operate and upgrade the platform. Model those hours by role and by year, and ask any partner to price the work in a written scope.

Sizing for peak concurrency

Models built on average task volume undersize schedulers, workers and the metadata database. Size for peak concurrency, including backfills, catch-up runs and the busiest scheduled windows. Load-test with representative DAGs and confirm worker slots and database connection limits before you approve hardware or cloud spend.

Airflow 3 components

In Airflow 3 the webserver is replaced by an API server started with airflow api-server, and the DAG processor must run as a separate component. A model that counts only a scheduler, workers and a web tier omits services. Add capacity, monitoring and failover for the DAG processor and API server, and confirm how your deployment method runs them.

Database choice for production

The production guide warns that the default SQLite backend is for testing only and can lead to data loss. The prerequisites also exclude MariaDB as a metadata database. Budget for PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or an Innovation release, plus backups, failover and the database administration time that comes with them.

Airflow 2 end of life and upgrade cycles

Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, after which it gets no fixes. A model that plans on Airflow 2 must add a migration. Upgrades also need Airflow 2.7 or later first, and provider packages and DAG checks recur. Confirm the current patch release and budget for both.

Hybrid executor assumptions

CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0. A model that prices a split between Celery and Kubernetes capacity in one hybrid class must be replaced with a supported setup. Since Airflow 2.10.0, several executors can run in one deployment, so confirm that design and its operating cost before the estimate is final.

How the cost picture changes by starting point

A managed service moves part of the operating work onto a vendor invoice, but the client still carries several costs. Compare the two options on the same scope.

Typically bundled by the vendor:

Hosted scheduler, web interface and metadata database operations, as described in that vendor's documentation
Upgrades and patching of the managed control plane
Worker capacity scaling, depending on the plan selected

Still owned by the client:

DAG code, testing and the release process
Integrations, connections and credentials for source and target systems
Data residency, network paths and where task logs are stored

Confirm each vendor's terms for supported versions, availability commitments, data location and exit options before comparing totals.

What you need to provide

A cost model for self-hosted Airflow is only as good as the inputs behind it. Before a partner can estimate infrastructure, executor capacity or support effort, your team needs to supply workload facts and name two owners: one for finance inputs (budget lines, internal labor rates, procurement rules, and any existing managed service quotes) and one for technical inputs (architecture, hosting and security requirements).

On the technical side, list the current or planned DAG count, the run frequency of each DAG, and estimates of task duration and peak concurrency. Add the data sources and sinks each pipeline touches, and state where Airflow will run: cloud accounts, data centers, or an existing Kubernetes cluster. Also record your preferred metadata database platform. The Airflow prerequisites list the supported PostgreSQL and MySQL versions, and MariaDB is not supported as a metadata database, so confirm the database choice against that list before modeling it.

Identity and secrets requirements change the model more than teams expect. Document your identity provider, how groups should map to Airflow roles, which secrets backend your organization already operates, and any compliance drivers that set logging, retention or access review obligations. Confirm these with your security and compliance leads rather than assuming defaults.

Finally, name the internal roles that will own Airflow after go-live, such as a platform owner, a pipeline developer lead and an on-call rota. Ownership gaps are the most common source of unbudgeted recurring effort. If you hold managed Airflow quotes, share the full written scope with them, including what support, upgrades and database operations each one covers, so the comparison is like for like.

Frequently asked questions

Is there a paid edition of Apache Airflow from the project?

No. Apache Airflow is released under the Apache License 2.0 (SPDX: Apache-2.0), and the Apache Software Foundation project itself offers no paid edition. Vendors sell managed services and support packages around Airflow, but those are separate products with their own terms. Confirm directly with each vendor what its offering includes, how it is priced and which Airflow versions it supports before you compare it with self-hosting.

What does self-hosting Airflow cost compared with a managed service?

The software is free, so the cost is what your organization pays to run it. Self-hosting costs usually come from:

Metadata database hosting and backups
Compute for schedulers, API servers, DAG processors and workers
Executor capacity and any Kubernetes or VM platform it runs on
Secrets and identity tooling
Staff time for upgrades, patching and on-call
Any support agreement

A managed service bundles much of this into a subscription. Compare the two using written quotes for the same workload, environments, availability expectations and upgrade work. Figures come from your own quotes, not from this page.

How long does an Airflow cost review take?

The length depends on how many environments, DAGs and executors are in scope, how well the current setup is documented, and whether the review includes a migration from Airflow 2 or another scheduler. A clear workload inventory and access to cloud billing data speed the work. Unknown dependencies, custom operators and undocumented connections add discovery time. Ask for the review steps, the inputs you must provide and the point at which a written scope and timeline are agreed before work starts.

Can our own team estimate Airflow costs without a partner?

Yes, if the team has the skills behind each cost line. Someone must size the metadata database and its backups, understand how schedulers and executors scale, model Kubernetes or VM capacity, and estimate the effort for upgrades and secrets handling. Platform engineers and data platform owners usually cover most of this, while security and finance staff are needed for controls and budget approval. A partner mainly adds a structured cost model, an independent check of assumptions and a written scope.

Does moving to Airflow 3 change the cost of running it?

Yes, it can. Airflow 3 replaces the webserver with an API server started with airflow api-server, and the DAG processor must run as a separate component, so you plan and run more services than a typical Airflow 2 setup. Airflow 2 reached end of life on April 22, 2026 and gets no fixes, so staying on it shifts cost into security exposure and unsupported operation. Upgrading also requires Airflow 2.7 or later first, plus DAG code checks with the Ruff AIR301 and AIR302 rules.

What should we ask for in a self-hosted Airflow quote?

Ask for a written scope that names environments, executors, DAG delivery method, secrets backend and identity integration, plus the assumptions behind each estimate. Separate one-time work, such as design, build and migration, from recurring items, such as infrastructure, support hours, patching and upgrades. For support, ask for covered hours, response terms and what counts as an incident. Also ask what happens at upgrade: whether it is included, how provider package changes are handled and how the cost changes when the next major version arrives.

How DeployOpen works on this

DeployOpen models the cost of running Apache Airflow in infrastructure you control, from the Apache-2.0 software through the people, capacity and support that surround it. The written scope sets out which components are priced, which recur and what a fixed-scope quote should include.

How we scope

The written scope lists each cost component: infrastructure, metadata database, executor capacity, people and support.
We separate one-time work such as the initial build from recurring work such as upgrades, patching and on-call duties.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We model the Airflow 3 component layout, including the API server and separate DAG processor, against your target hosting.
We compare self-hosted running costs with managed Airflow service terms using the same workload assumptions.
We document the assumptions behind every cost line so your finance and platform teams can test them.

How we hand over

You receive a cost model with its assumptions, cost drivers and the items you need to confirm with each vendor.
We document the support lifecycle, including which Airflow versions remain supported and when upgrades fall due.
Runbooks cover how recurring work is performed, so your team can own the platform after handover.

How we support

Ongoing support, upgrades and testing are available as retainers, priced from the scope agreed for your environment.
We can review the cost model again when executor choice, database sizing or workload volume changes.
Support scope is defined in writing, so you know which upgrade, patch and incident work the retainer covers.