Apache Airflow vs Mage: which to choose for self-hosted pipelines
Choose Apache Airflow when your team wants a scheduler-centred platform it can operate for years. Airflow fits teams that already run DAG-based pipelines, need fine control over scheduling and retries, or must move off Airflow 2 now that it has reached end of life on April 22, 2026, according to the Airflow version support table. The move to Airflow 3 is a real project in its own right, so budget time for reviewing DAGs against the upgrade guide. Airflow also lets you mix executors in one deployment since Airflow 2.10.0, which matters when some tasks suit long-running workers and others suit one pod per task. Choose Mage when your engineers want to build pipelines block by block in Python, SQL or R, debug each block with logs and data previews, and run dbt models from the same editor. Mage OSS is licensed under Apache-2.0, but its own README positions it as a self-hosted development environment, so plan for that before you treat it as the production orchestrator.
The decision turns on four questions. First, who will operate the production system, and whether that team wants to run a metadata database, schedulers and workers as a platform or prefers a lighter tool. Second, whether you will run tasks on Kubernetes, and if so, whether the Kubernetes executor and workspace features you need sit in the open-source edition or in paid Mage Pro, which Mage's Helm guide says applies to workspaceConfig and k8sExecutorConfig. Third, whether PostgreSQL and, for multiple replicas, Redis are acceptable components in your environment, since Mage's Helm guide requires them for production. Fourth, whether Mage Pro is in the budget at all. Ask Mage for a written list of which features a production deployment requires, and test the open-source edition against your real failure cases before committing. Confirm each Airflow prerequisite against your platform's version in the Airflow prerequisites page.
Which platform fits which team scenario
This table matches six team situations to the platform that usually fits them better in an Apache Airflow vs Mage decision. Each row states the condition under which the better fit holds and what to confirm in writing before committing. The main takeaway: Airflow suits Python-first estates, existing DAGs and Kubernetes-run platforms, while Mage suits teams that author pipelines in a block editor and can plan for paid Mage Pro features.
| Team scenario | Better fit | Condition under which it holds | What to confirm with the vendor |
|---|---|---|---|
| Existing Airflow 2 DAGs past end of life | Apache Airflow 3 | Migration keeps Python DAGs and the scheduler model. Airflow 2 has received no fixes since April 22, 2026. | The Airflow 3 upgrade steps for your DAGs and plugins. Mage would mean rewriting DAGs as blocks. |
| Small team building new pipelines in notebook style | Mage OSS | The team prototypes in a block editor with Python, SQL or R and wants data previews during development. | Whether Mage intends the open-source edition for production runs, since it positions OSS as a development environment. |
| Platform team standardising on Kubernetes execution | Apache Airflow | Open-source KubernetesExecutor, combined with other executors since 2.10.0, fits a cluster-first standard. | That Mage's k8sExecutorConfig is available only in Mage Pro, and the Airflow 3.3.2 support for your Kubernetes version (1.30 to 1.35). |
| Team needs dbt models run inside the pipeline tool | Mage OSS, if dbt is the main workload | Mage lists building and running dbt models inside Mage as a built-in capability. | The dbt adapters and versions Mage supports, and how your dbt projects run under each tool. |
| Team needs SSO and audit controls from day one | Evaluate both before choosing | The right answer depends on which access and audit features your chosen edition or auth manager includes. | Which SSO, role-based access and audit logging features sit in Mage Pro and which Airflow auth manager you would deploy. |
| Team running production on a shared metadata database | Apache Airflow | PostgreSQL 14 to 18 or MySQL 8.0 and Innovation releases with multiple schedulers meet the production guidance. | The database sizing and high-availability setup for your load, and Mage's PostgreSQL and Redis requirements for multiple replicas. |
How Airflow and Mage are built and what that means for operations
Airflow splits scheduling, parsing, serving and state across several components that you run and upgrade yourself. Mage packs its pipeline editor around a database and, in production, a Redis layer for replicas. The cards below cover what each design leaves with your team.
Airflow's four core components
Airflow 3 runs a scheduler, a DAG processor, an API server and a metadata database as separate parts of one deployment. Each needs its own process supervision, logs and health checks, and the database holds every DAG run, task state and connection history. The production guide recommends PostgreSQL or MySQL, and the prerequisites say SQLite should not be used in production. Check that your team can run and back up that database before you commit.
Scheduler high availability
Airflow supports running more than one scheduler at the same time, coordinated through database row-level locks. That gives resiliency and throughput, but it also means your metadata database becomes the coordination point and a capacity planning concern. Ask whether your database tier can absorb the lock contention of the scheduler count you plan to run.
Choosing among Airflow executors
Airflow ships LocalExecutor, CeleryExecutor, KubernetesExecutor, EdgeExecutor and AWS Batch and ECS executors. Since Airflow 2.10.0, several executors can run in one deployment, but the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0. Each executor choice sets who manages workers, queues and task isolation, so decide it before you build DAGs around it.
Mage's block editor and production state
Mage OSS builds pipelines block by block in Python, SQL or R in a notebook-style editor, which suits local development. The Helm guide states that PostgreSQL is required in production for pipelines, triggers and metadata, and that Redis is required when you run more than one replica for distributed locking and caching. Confirm that your team will operate both services, and check whether the Kubernetes executor and workspace options you need sit in Mage Pro.
Mage paid-only Kubernetes options
The Helm guide says the workspaceConfig and k8sExecutorConfig settings work only in Mage Pro and are ignored when you run Mage OSS. A team that expects per-task pods or shared workspaces on Kubernetes should price that gap into its design. Ask Mage in writing which features your target deployment needs and whether they are available in the edition you plan to run.
Helm, Docker and pip installs
Airflow's official Helm chart, production Docker images and PyPI install all leave dependency, upgrade and security patching work with your team. Mage installs through Docker (recommended), pip or conda, and its Helm guide sets the production database and Redis requirements. Both designs assume you own the upgrade cadence, so test each release in a staging environment that mirrors your database and executor setup.
Capability comparison: scheduling, dbt, databases and identity
This table compares Apache Airflow and Mage on the capabilities that shape day-two operation: licensing, scheduling, dbt, metadata databases, executors, memory, Kubernetes execution and identity. Where the supplied documentation does not settle a row, the cell names what to confirm with the vendor or in a test environment. The main takeaway is that Airflow's production requirements are documented in detail, while Mage's production path on Kubernetes depends on the Pro edition.
| Capability | Apache Airflow | Mage |
|---|---|---|
| License | Apache-2.0 with no paid edition from the Apache Software Foundation project | Open-source Mage is Apache-2.0 per its GitHub metadata; Mage Pro is a paid platform |
| Authoring model | Python DAGs defined in code and versioned in your repository | Notebook-style blocks written in Python, SQL or R, built and previewed in the editor |
| Scheduling | Airflow scheduler runs DAGs on schedules, and several schedulers can run at once | Manual runs or cron scheduling, with prebuilt connectors to databases, APIs and storage |
| dbt support | Run dbt through Airflow operators; confirm the provider package and version you need | Builds and runs dbt models inside Mage pipelines; confirm the dbt versions it supports |
| Metadata database and shared state | PostgreSQL 14 to 18 or MySQL 8.0 and 8.4; SQLite is for testing only and MariaDB is unsupported | PostgreSQL required in production; Redis required for more than one replica, for locking and caching |
| Executors and multi-executor support | Several executors can run in one deployment since 2.10.0; hybrid Celery and Local Kubernetes executors were removed in 3.0.0 | Kubernetes execution settings are supported only in Mage Pro; confirm the executor options in OSS |
| Kubernetes execution | KubernetesExecutor runs each task in its own pod; Kubernetes 1.30 to 1.35 is supported | Kubernetes executor configuration is ignored in Mage OSS and applies only in Mage Pro |
| RAM guidance | At least 4 GB of RAM is recommended in the Airflow prerequisites | No sizing figure in the supplied material; ask Mage for guidance before planning hardware |
| Identity and audit | Access control is set by the auth manager; confirm the SSO and audit options in your version | Workspace features sit in Mage Pro; confirm what Mage OSS offers for user access and audit |
What is free and what is paid in each platform
Apache Airflow is an Apache Software Foundation project released under the Apache License 2.0, and the project itself offers no paid edition. Every scheduler, executor, API server and provider capability in the release you install comes under that license, so there is no feature gate to pass in the open-source code. Commercial value arrives from separate companies that run or support Airflow for you, and those contracts are priced on their own terms.
- License: Apache-2.0 for the project, with no enterprise tier from the Apache Software Foundation.
- Recurring cost: your own compute, the metadata database, and the staff who upgrade and patch it.
- Managed services: offered by separate vendors, each with its own rates and feature boundaries.
- Support windows: Airflow 2 reached end of life on April 22, 2026, so only Airflow 3 receives fixes today.
- Prerequisites: PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases, not MariaDB or SQLite.
Confirm with any managed vendor which Airflow version they run, which executors they expose, and what their published rates include.
The Mage repository is licensed under Apache-2.0, so the code you download is open. The Mage README positions Mage OSS as a self-hosted development environment for building pipelines locally, and its notebook-style block editor, scheduling and dbt support sit in that edition. Mage's own documentation separates the open-source product from the paid platform, so read the README and Helm guide before you assume a capability is in the free build.
- License: Apache-2.0 for the repository, per its GitHub license metadata.
- Intended use: a self-hosted development environment for building pipelines locally.
- Included features: block-based authoring in Python, SQL or R, manual or cron scheduling, connectors, and dbt model runs.
- Kubernetes limits: the Helm guide says
workspaceConfigandk8sExecutorConfigare ignored when running Mage OSS. - Production needs: PostgreSQL is required for pipelines, triggers and metadata, and Redis is required with more than one replica.
Check the Mage Pro feature list against the production capabilities you need before you commit to the open-source build.
Mage Pro is the company's core paid platform, which the Mage README presents as the product for enterprise orchestration, collaboration and AI-powered workflows. The features the Helm guide names as Pro-only are the Kubernetes executor configuration and workspace configuration, so teams that run pipelines on Kubernetes or share workspaces across users should expect to need it. The published material does not give Mage Pro pricing or a complete feature list in the sources reviewed here.
- Kubernetes executors:
k8sExecutorConfigis supported only in Mage Pro. - Workspaces:
workspaceConfigis supported only in Mage Pro. - Collaboration and enterprise orchestration: positioned as Pro scope in the README.
- AI-powered workflows: positioned as Pro scope in the README.
- Cost driver: the commercial agreement, which is not a public price in these sources.
Ask the vendor for the Mage Pro feature list, the price and the licensing terms in writing, including what happens to your pipelines if you later move back to OSS.
The license tells you what you may run without paying, but total cost depends on the infrastructure and people behind it. In both platforms the recurring costs are your compute, your database and the engineering time needed to upgrade and operate the system. A quote should separate one-time implementation work from recurring subscription, support and infrastructure charges, so you can compare the two platforms on equal terms.
- Infrastructure: Airflow needs a supported metadata database and scheduler capacity, while Mage production setups need PostgreSQL and, with replicas, Redis.
- Subscriptions: Mage Pro is a paid tier, while Airflow subscriptions come only from third-party providers.
- Upgrades: Airflow 2 is past end of life, so any Airflow 2 estate needs an upgrade path with a cost of its own.
- Support: confirm response terms, supported versions and what the vendor covers in writing.
- Exit: confirm export formats for pipeline code and metadata if you later change platforms.
Request a written scope that lists each paid feature you need, the upgrade path and the recurring charges, then compare those lines across both platforms.
What drives the running cost of each platform
Both platforms are free to download under permissive or copyleft open-source terms, so the running cost comes from the infrastructure they need, the people who operate them, and any paid tier you decide to buy. The cards below separate those components so you can ask each vendor or partner for a quote that matches your own environment.
Airflow infrastructure footprint
Airflow runs a scheduler, a DAG processor, an API server and a metadata database, and the project's prerequisites recommend at least 4 GB of RAM. Ask whether you need more than one scheduler, since Airflow supports running several at once using database row-level locks, and size the metadata database as a managed or self-run service with backups. Plan for these components as recurring compute and storage, not a one-time install.
Mage production dependencies
Mage's Helm guide states that PostgreSQL is required in production for pipelines, triggers and metadata, and Redis is required when you run more than one replica for distributed locking and caching. Those are the two services you add to your recurring footprint. Confirm how many replicas your pipeline volume requires and who runs the database backups and Redis failover in your environment.
Operator skills and on-call load
Airflow is a long-running platform with a scheduler, executors and a database, so the team that runs it needs Python, Kubernetes or Celery operations and a rota for failed runs. Mage's notebook-style editor lowers the authoring barrier, but production operation still needs the same database and container skills. Estimate the on-call hours your team can absorb before choosing, and ask any partner to write the escalation path into the scope.
Mage Pro licensing for Kubernetes
Mage's Helm guide says the workspaceConfig and k8sExecutorConfig options work only in Mage Pro and are ignored in Mage OSS. If you need Kubernetes execution or shared workspaces, that cost is a paid Mage Pro subscription on top of your infrastructure. Ask Mage for a written quote covering seats, support and the features you need, and compare it with the self-managed Airflow executor setup you would run instead.
Airflow 2 to 3 upgrade work
Airflow 2 reached end of life on April 22, 2026, so an Airflow 2 estate gets no fixes and needs a migration to Airflow 3. The upgrade is a one-time project covering DAG changes, executor choices and infrastructure updates, and the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported in Airflow 3.0.0. Ask for a fixed-scope estimate that lists the DAGs in scope and the testing each one needs.
Support and retainer options
Apache Airflow is an Apache Software Foundation project with no paid edition from the project itself, so community support is free but carries no response commitment. Mage offers paid Pro support, and DeployOpen offers fixed-scope implementation plus ongoing support, upgrades and testing as retainers. Ask each provider what response times, upgrade help and out-of-hours coverage are included and whether they are written into the contract.
Upgrade cadence and version drift
Airflow publishes version support windows, and its 3.x line moves through patch releases such as 3.3.2, so you need a scheduled upgrade routine rather than occasional catch-up work. Mage ships frequent releases, including 0.9.80 on October 9, 2026, and the OSS and Pro features can diverge. Budget recurring testing time for each upgrade, and ask any vendor how long each supported version receives fixes.
Moving pipelines from Airflow to Mage, or from Mage to Airflow
This sequence gives a team a dependable path to move pipelines in either direction without losing schedules, credentials or data correctness. It ends with both systems running side by side and a documented cutover decision.
Inventory every pipeline and its dependencies
The data platform lead and the pipeline owners list each Airflow DAG or Mage pipeline, its schedule, its upstream and downstream systems, its dbt models, and the people who depend on its outputs. Record which Airflow version runs each DAG. Any Airflow 2 DAG should be flagged now, because Airflow 2 reached end of life on April 22, 2026 and gets no fixes. The inventory is done when every pipeline has an owner, a schedule and a named consumer, and the team agrees on the list.
Classify each pipeline as transfer or rebuild
For each item, the team decides whether the logic moves as code or is rebuilt in the target tool's model. Plain Python tasks and standard SQL may be ported with modest changes. DAGs that rely on Airflow-specific operators, custom executors, sensors or XCom patterns usually need redesign. Mage pipelines built from blocks and notebook-style steps map more directly to a new block structure than to a DAG file. Ask whether each pipeline still has a business reason to exist before porting it. The output is a classified register that names the target design for every pipeline.
Map connections, variables and secrets
Airflow stores connections and variables in its metadata database or a configured secrets backend. Mage uses its own configuration and secret handling, and its Helm guide requires PostgreSQL for pipelines, triggers and metadata in production. The platform engineer exports connection definitions, rotates credentials where needed, and loads them into the target through the target's approved secrets mechanism, not as plain text in code. Confirm each source and target connector exists in the target tool before moving a pipeline. Done means every connection resolves in a test run and no credential appears in a repository.
Rebuild schedules and dbt runs
The team recreates each schedule in the target tool. Mage OSS supports manual or cron scheduling, and Airflow expresses schedules in DAG code, so cron expressions and time zones need a line-by-line check. dbt projects should be run with the same model selection, target profile and test steps as before. Confirm that dbt models run inside Mage or as Airflow tasks, and that dependencies between dbt runs and upstream loads are still enforced. Done means each schedule has a recorded next run time that matches the original, and dbt test results match the baseline.
Parallel-run and compare outputs
Both pipelines run against the same sources for an agreed period, writing to separate target schemas. The data owner compares row counts, key totals, freshness and sample records between the two outputs, and the team logs every mismatch with a cause. Failures and retries are compared too, since the two tools handle them differently. The check is complete when the owner signs off that outputs match within the tolerance agreed in the inventory step. Length of the parallel period is a decision for the team and should be set in the written scope, not guessed in advance.
Document what does not transfer directly
Some elements will not carry across in a straight port. Airflow DAG code and Mage block structure differ in how state, dependencies and parameters are expressed, so custom operators, Airflow-specific plugins, auth manager settings and executor choices need separate decisions. Mage features such as workspaces and Kubernetes executors sit in Mage Pro, so a team moving to OSS should confirm it does not depend on them. The architect writes a gap register listing each item, the chosen replacement and the owner. Done means no pipeline depends on an unlisted feature.
Cut over and retire the old pipelines
After sign-off, the team switches consumers to the new outputs, pauses the old schedules, and keeps the old definitions and metadata for a retention period set in the written scope. Monitoring and alerts move to the new platform before the old one is switched off. The runbook is updated with the new operating model, including who patches the platform and how backups run. The cutover is complete when the old schedules are paused, alerts fire from the new platform in a test, and the decommission record is signed by the data owner and the security lead.
Running either platform in production without surprises
The first production decision is the metadata database, and the two platforms draw the line in different places. Airflow's production deployment guide warns that the default SQLite backend is for testing only and can lose data in production, and its prerequisites add that MariaDB is not supported as a metadata database. Plan for PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or an Innovation release from day one, and confirm the exact combination against the Airflow prerequisites for the version you deploy. If you plan to run more than one scheduler for resiliency, Airflow coordinates them with database row-level locks, so the database sizing and failover design become part of the scheduler design.
Mage's production story is also centred on PostgreSQL, but for a different set of state. Its Helm guide says PostgreSQL is required in production for pipelines, triggers and metadata, and Redis is required once you run more than one replica, for distributed locking and caching. A team that moves Mage OSS from a single Docker container to several replicas must add Redis and confirm that the locking behaviour works in its own cluster before go-live. Treat the Helm guide's production requirements as the minimum, and test failover with a pipeline mid-run rather than assuming replicas are safe.
Whichever platform you choose, the team keeps the operating work that no vendor does for you: backups of the metadata database and pipeline state, restore tests, version upgrades, and monitoring of scheduler health, queue depth and failed runs. Airflow 2 is past end of life, so any upgrade path into Airflow 3 should be planned as a project with its own test window. For Mage, confirm which of the Helm options such as workspace and executor configuration apply to your edition before you design the rollout, because those settings are ignored on Mage OSS. Ask each vendor, or your implementation partner, to document the backup, restore and upgrade procedure in writing before the platform carries production schedules.
Questions buyers ask before choosing Airflow or Mage
Is Mage open source enough for production?
Mage's README positions Mage OSS as a self-hosted development environment for building pipelines locally, and it reserves enterprise orchestration, collaboration and AI-powered workflows for Mage Pro. The repository is licensed under Apache-2.0, so the code is open, but the vendor's stated product direction for production sits in the paid tier. Mage's Helm guide also says that workspaceConfig and k8sExecutorConfig are supported only in Mage Pro and are ignored when running Mage OSS. A production open-source deployment needs PostgreSQL for pipelines, triggers and metadata, and Redis once you run more than one replica. Ask Mage in writing which production support, upgrades and security fixes apply to the open-source edition before you commit.
Does Airflow 2 still get fixes?
No. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, after which it receives no fixes. During limited maintenance, only security and critical bug fixes were provided, and the last Airflow 2 patch is 2.11.2. Airflow 3.3.2 is the current release. Any Airflow 2 estate still running carries unpatched exposure, so the upgrade is a security item as well as a feature question. Inventory your DAGs, custom operators, plugins and connections first, then check them against the Airflow 3 upgrade guide. Moving to Mage also requires this inventory, because Mage pipelines are built as blocks and each one must be rebuilt.
Which platform needs a PostgreSQL database, and why?
Both platforms depend on a relational database, and PostgreSQL is the safest production choice for each. Airflow stores its metadata in a database, and its production guide recommends PostgreSQL or MySQL, because the default SQLite backend is for testing only. The Airflow 3.3.2 prerequisites list PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases, while MariaDB is not supported as a metadata database. Airflow runs multiple schedulers through database row-level locks, so the database also limits how resilient the scheduler can be. Mage's Helm guide requires PostgreSQL in production for pipelines, triggers and metadata. Ask each vendor which database versions it tests against, and have your DBA confirm backup and restore responsibilities.
Can Mage run dbt models in production pipelines?
Yes, according to Mage's README, which lists building and running dbt models inside Mage as a feature of the open-source tool. Airflow orchestrates dbt through the operators, containers or community packages you choose, so the pattern is your decision and your maintenance. Confirm the exact approach for your dbt version and warehouse adapter before you commit. Check how your project's profiles and warehouse credentials are stored, how dbt test failures stop downstream tasks, and how long a full run takes on your infrastructure. Ask Mage to run a representative project from your own repository in a test environment, and compare the outputs with your current dbt runs before any cutover.
What does Mage Pro add, and what does it cost?
Mage's README describes Mage Pro as its core paid platform for enterprise orchestration, collaboration and AI-powered workflows. The Helm guide adds that workspaceConfig and k8sExecutorConfig work only in Mage Pro. No Mage Pro price was supplied for this page, so confirm pricing, billing unit, support terms and renewal terms directly with Mage. Costs recur through the subscription, your compute, PostgreSQL, Redis and staff time. Ask for a quote that lists the features you need, such as Kubernetes executors and workspaces, the number of users and environments, and the support level. DeployOpen is not an official Mage reseller and does not publish a price list, so its quote covers only the implementation scope you agree in writing.
How much effort does migrating from Airflow take?
Effort depends on how much logic lives in your DAGs and what they connect to. Start with an inventory of DAG count, custom operators and plugins, connections and variables, sensors, cross-DAG dependencies, and the schedules and backfills your team relies on. Airflow DAGs are Python code, while Mage pipelines are built block by block in Python, SQL or R, so each pipeline must be restructured and retested. Neither platform's supplied material gives a migration duration, so ask for a timeline based on your inventory. Illustrative example: a team whose DAGs mostly run dbt will likely spend more time comparing outputs than writing new blocks.
Can our team migrate alone, or do we need outside help?
It depends on skills and capacity as much as on the tool. Your team needs Python, operation of Kubernetes or hosts, PostgreSQL administration, and a plan for upgrades and security patches. 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, and ongoing support is available as a retainer. DeployOpen is not an official Mage or Airflow partner. Ask any implementation partner for a written scope that names platform versions, environments, data sources, handover documents and who signs off the cutover.
Is Airflow's free license the same as free support?
No. Airflow is licensed under Apache-2.0, and the Apache Software Foundation project offers no paid edition of its own. The license fee is zero, but the running cost is not, because you pay for infrastructure, staff and any support contract you choose. Mage OSS is also Apache-2.0 at the repository level, but its paid Pro tier holds the enterprise features. For a regulated team, the key question is who carries patching, upgrades and incident response across the platform's life. Ask each option what its subscription covers, which versions it supports, and what happens to your pipelines when a support window closes. The Airflow 2 end-of-life date shows why this matters.
Four checks to run before committing to either platform
Both platforms look similar on a feature sheet, but the costs and risks sit in the details: which features are paid, what the database layer requires, how access is controlled, and what happens to existing DAGs. Run these four checks against vendor documents and your own environment before you commit.
Confirm Mage Pro terms in writing
Mage's README positions the open-source edition as a self-hosted development environment and places enterprise orchestration in Mage Pro. Ask Mage for a written list of the features you need, including Kubernetes executors, workspaces and collaboration, and confirm which edition includes each one. Ask whether the terms cover support, upgrades and any usage limits, and whether they change between releases. Put the answers in the contract file, since the README alone does not settle what your production setup will need to pay for.
Confirm database and Redis requirements
Mage's Helm guide says PostgreSQL is required in production for pipelines, triggers and metadata, and Redis is required when running more than one replica. Airflow 3.3.2 supports PostgreSQL 14 to 18 or MySQL 8.0, 8.4 and Innovation releases, and does not support MariaDB as a metadata database. Ask your DBA and platform team to map both stacks onto your existing database standards, backup tooling and high availability design. Confirm the versions against the current docs on the day you decide, because the supported lists change with each release.
Confirm identity and audit controls
Access control and audit logging decide whether either platform can pass your security review. Airflow uses an auth manager component, so ask which authentication and role model your release uses and how it maps to your identity provider. For Mage, ask whether SSO, role-based access and audit logs are included in the open-source edition or only in Mage Pro. Request the vendor's written answer and test the log export and group mapping in a staging environment before you rely on either.
Confirm the Airflow version path
Airflow 2 reached end of life on April 22, 2026, so existing DAGs need an upgrade to Airflow 3 before any new work starts on that estate. Inventory your DAGs for removed features, including the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor, which are no longer supported as of Airflow 3.0.0. Estimate the migration effort from that inventory, and compare it with the effort of rewriting pipelines as Mage blocks. Ask your team to run a pilot DAG on the target version before setting a deadline.
How DeployOpen helps teams choose and implement either platform
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the choice between Airflow and Mage can be tested against your environment before anything is built. Most engagements are fixed-scope: the scope, deliverables and timelines are agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not favour either platform and does not publish a price list. A quote follows from the written scope.
A useful written scope for this decision names the things that actually separate the two products: whether your team will author pipelines as Python DAGs or as notebook-style blocks, which executor model you need, whether you need Kubernetes executors or workspaces (which Mage's Helm guide places in Mage Pro), which metadata database you will operate (PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases for Airflow 3.3.2, and PostgreSQL with Redis for multi-replica Mage), and how dbt models will be run. Ask us to test those points against a working copy of your own pipelines, and ask your vendors to confirm which features are in the open-source edition and which sit in a paid tier.
The written requirements should also cover what happens after go-live: who applies upgrades, who restores the metadata database, how secrets and SSO are handled, and where logs and audit evidence are kept. These are the costs that recur. DeployOpen can document them as runbooks, harden the deployment, and support it under a retainer, while the license and edition decisions remain yours and your vendors'. Send your requirements in writing and we will return a fixed-scope proposal that states what is included, what you need to provide, and how the work is verified.
