What is the main difference between dbt and Apache Airflow?

dbt is a SQL transformation tool that runs inside your data warehouse. It does not move data or connect to external systems. Apache Airflow is a general-purpose workflow orchestrator written in Python that can connect to dozens of external systems and orchestrate any type of task. Many production stacks use both: Airflow to schedule and trigger dbt runs as one step in a larger pipeline.

What actually changed in Apache Airflow 3.0?

More than most comparisons written before mid-2025 account for. Airflow 3.0, released April 2025, is the largest release since 2.0 in 2020. The headline feature is DAG versioning: a running DAG now completes on the version it started with even if a new version is deployed mid-run, which eliminates the workflow-drift bugs that plagued 2.x. Tasks also lost direct access to the metadata database, replaced by a hardened Task Execution API, a real security architecture change, not just a UI refresh. There's also a new React-based UI and CLI/UI-driven backfills.

When should I choose dbt over Apache Airflow?

Choose dbt when your pipeline is entirely SQL transformations inside a single warehouse like Snowflake, BigQuery, or Redshift and your team works primarily in SQL. dbt Core is free under Apache 2.0 and a working project can be running in hours. dbt Cloud's Starter plan at $100 per seat per month covers 5 seats, with per-model-build overage billing once you exceed the plan's included allocation.

When should I choose Apache Airflow over dbt?

Choose Apache Airflow when you need to orchestrate workflows that span multiple systems: pulling from APIs, moving files, triggering Spark jobs, or running ML training before or after warehouse transformations. Its wide PyPI download base and provider ecosystem reflect its dominance as the default orchestrator for complex, multi-system data pipelines.

What does dbt cost and is there a free tier?

dbt Core is completely free under the Apache 2.0 license with no usage limits. dbt Cloud's Developer tier is free for one seat, one project, and a capped number of model builds. The Starter plan runs $100 per seat per month for 5 seats, plus a per-model overage fee past the included build allocation. Enterprise pricing is available on request for organizations needing SSO, audit logs, and dedicated support.

What is the biggest production failure mode in Apache Airflow that teams discover too late?

The most dangerous default is running Airflow with SQLite as the metadata database and LocalExecutor in production. Under meaningful concurrency, SQLite deadlocks, causing task instances to become orphaned while the scheduler continues spawning new attempts. The result is silent duplicate execution with no alert. Always configure PostgreSQL as the metadata database and use CeleryExecutor or KubernetesExecutor before going to production, not after your first incident. This is unrelated to the Airflow 3.0 task-database-access change, which is about task isolation, not scheduler metadata storage.

How difficult is it to migrate from Apache Airflow to dbt or vice versa?

Migrating from dbt to Airflow is additive: you keep your dbt project and wrap it in an Airflow DAG using the dbt provider package. Migrating from Airflow to dbt is only possible if your pipelines are transformation-only with no upstream ingestion or cross-system steps. Airflow DAGs that touch APIs or move files between systems cannot be replaced by dbt, only the transformation portions can be moved.

What does managed Airflow actually cost now that Cloud Composer changed pricing?

More than the old flat per-hour figure many comparisons still quote. Google rebranded Cloud Composer to a consumption-based model in 2025, billed by Data Compute Unit hours, GB-months, and network egress, not a flat per-hour rate. Real-world minimal setups run roughly $300/month, with production deployments landing between $500 and $1,500/month depending on scale. If you're comparing against a source citing a flat $0.30-something-per-hour Composer rate, that pricing model no longer applies.

How popular is Apache Airflow compared to dbt in 2026?

Both remain among the most widely deployed tools in their respective categories: Airflow as the default general-purpose orchestrator with a large PyPI download base and provider ecosystem, dbt as the dominant tool in the analytics-engineering category it largely created. Star and download counts move fast enough that a specific snapshot number ages within months; check each project's GitHub page directly for a current figure rather than trusting a fixed number in any article, including this one.

Tech Duel

dbt vs Apache Airflow

dbt transforms data with SQL inside your warehouse and stays out of everything else. Apache Airflow orchestrates workflows across any system in Python, and shipped its biggest release in years, Airflow 3.0, in April 2025. The right pick depends on whether your pipeline is warehouse-only transformations or spans multiple systems.

Last reviewed: July 2026

Quick verdict: dbt vs Apache Airflow

Choose dbt if your pipeline is entirely SQL transformations inside a single warehouse and you want a working project running in hours, not days.

Choose Apache Airflow if you're orchestrating multi-system pipelines that move data between APIs, databases, and warehouses and your team writes Python daily.

Managed Airflow pricing changed in 2025 — Google Cloud Composer moved off flat hourly rates to consumption-based billing, so check current numbers rather than an old per-hour figure.

When to choose dbt vs Apache Airflow

Choose dbt when…

Your pipeline is entirely SQL transformations inside one warehouse — Snowflake, BigQuery, Redshift, or Databricks
Your team works primarily in SQL and wants a working project running in hours
You want automatic data lineage, a browsable catalog, and column-level docs generated from your existing project
You don't need to move data between systems or trigger non-SQL work
dbt Core's free, unlimited Apache 2.0 license fits your budget better than a metered orchestrator

Choose Apache Airflow when…

You're orchestrating workflows that span multiple systems — APIs, file transfers, Spark jobs, ML training
Your engineering team already writes Python daily and can own DAG code
You need Airflow 3.0's DAG versioning to avoid workflow-drift bugs across long-running pipelines
You're already invested in Airflow's provider ecosystem for external system integrations
You can commit to production-grade infrastructure (PostgreSQL metadata DB, Celery or Kubernetes executor) rather than the defaults

That's the generic picture. Whether your pipeline is warehouse-only or multi-system is what usually tips it. ↓

dbt vs Apache Airflow: at a glance

Dimension	dbt	Apache Airflow
Scope	SQL transformations inside the warehouse	General-purpose workflow orchestration, any system
Language	SQL + Jinja (Python models via dbt-py on supported warehouses)	Python
Latest major version	Continuous dbt Core/Cloud releases	3.0 (Apr 2025) — DAG versioning, new Task Execution API, React UI
Data movement	None — warehouse-native only	Yes, via a broad provider ecosystem
Pricing	Core free (Apache 2.0); Cloud Developer free, Starter $100/seat/mo (5 seats) + per-model overage	Free (Apache 2.0); managed options metered (Composer DCU-hours, MWAA hourly)
Managed hosting cost	dbt Cloud Developer tier: free	Cloud Composer: ~$300/mo minimal, $500-1,500/mo production
Lineage & docs	Automatic DAG, catalog, column-level docs, built in	Needs OpenLineage integration for comparable depth
Production metadata store	N/A — uses the warehouse	Must be PostgreSQL/MySQL; SQLite is a production hazard
Task DB access (3.0+)	N/A	Removed — tasks run through a hardened Task Execution API
Typical team fit	Analytics teams, SQL-fluent	Platform/data engineering teams, Python-fluent

dbt vs Apache Airflow: what Airflow 3.0 actually changed

Airflow 3.0 shipped in April 2025, the largest release since 2.0 in 2020, and a lot of comparison content online, including earlier versions of this page, was written before it landed. The headline feature is DAG versioning: a running DAG now completes on the version it started with, even if a new version gets deployed mid-run. That directly fixes workflow drift, one of the most-requested fixes from Airflow's own annual user survey and a real source of inconsistent pipeline behavior in 2.x.

The less-discussed but arguably bigger change is architectural: tasks no longer have direct access to the metadata database. Task code can't reach into Airflow's internal models anymore; state transitions, XCom handling, and resource fetching all route through a new Task Execution API layer. That's a real security boundary, not a cosmetic change, and it matters for any team running untrusted or third-party task code. Airflow 3.0 also shipped a rebuilt React UI and CLI/UI-driven backfills.

None of this touches dbt directly, since dbt and Airflow solve different problems, but it does change the calculus for teams already running Airflow 2.x and weighing whether to stay, upgrade, or move transformation logic into dbt instead. If you're on 2.x specifically to avoid workflow-drift pain, that's now a solved problem in 3.0 rather than a reason to look elsewhere.

If you last evaluated Airflow before April 2025, re-check DAG versioning specifically. It resolves a complaint that used to show up in almost every "Airflow pain points" list.

dbt vs Apache Airflow: cost of ownership beyond the sticker price

dbt Core is genuinely free with no usage cap, but dbt Cloud's Starter plan ($100/seat/month for 5 seats) isn't purely flat either: exceed your plan's included model-build allocation and you're billed a per-model overage fee on top. A team running frequent CI builds against a large project can find that overage adds up faster than the flat seat price suggests, similar to how Supabase's and other "predictable pricing" platforms turn out to be metered past a threshold once you read the fine print.

Airflow's software is free, but production infrastructure never is. Self-hosting means a PostgreSQL metadata database, a message broker if you're running CeleryExecutor, worker machines, and ongoing engineering time, realistically 2 to 4 hours a week even once it's stable. Managed options remove that burden at a real cost: Cloud Composer's new consumption-based pricing lands around $300/month for a minimal setup and $500-1,500/month in production, and AWS MWAA runs on a comparable hourly-plus-worker model.

The team-size pattern holds up in practice: dbt fits analytics teams of roughly 1 to 20 people where most members already know SQL, while Airflow scales to platform teams of 50 or more engineers but effectively requires at least one engineer whose job includes Airflow operations, whether that's self-hosted maintenance or managing the managed-service configuration.

Model your actual usage, model builds for dbt, worker-hours for Airflow, against each pricing structure before assuming either one is the cheap option.

Production gotcha: what nobody tells you

Apache Airflow's gotcha is task instance state corruption under high concurrency when you mix the LocalExecutor with a SQLite metadata database, which is the default out-of-the-box configuration. Teams run this in staging, it works fine for months, then they push a DAG with 50 parallel tasks in production and the metadata DB deadlocks, orphaning task instances with no clean recovery path other than a manual database surgery. The Airflow docs tell you to use PostgreSQL or MySQL for production but bury that requirement. Most teams discover it the hard way at 2am on a Tuesday when a critical pipeline silently stops marking tasks as complete while the scheduler keeps spawning duplicates. Switch to CeleryExecutor with PostgreSQL before you go live, not after.

dbt vs Apache Airflow: running them together in production

The most common real-world setup isn't a choice between the two, it's both, in the same stack. Airflow orchestrates the full pipeline: triggering ingestion, waiting on upstream dependencies, handling retries and alerting, then calling dbt as one step to run the actual warehouse transformations. The official dbt provider package for Airflow makes this a supported, documented pattern rather than a workaround.

This division of labor maps to what each tool is actually built for. dbt has no concept of waiting on an external API or triggering a Spark job; it only knows how to run SQL against your warehouse. Airflow has no opinion about SQL transformation logic, dependency graphs between models, or generating documentation, that's dbt's job. Teams that try to replicate dbt's transformation-layer ergonomics directly in Airflow DAGs generally end up rebuilding a worse version of what dbt already does.

The asymmetry shows up when migrating rather than combining. Adding Airflow to an existing dbt project is additive, wrap the existing project in a DAG and you're done. Moving away from Airflow toward dbt-only only works if every pipeline is warehouse-only transformation with no ingestion or cross-system steps; anything that touches an API or moves files has to stay in Airflow or move to a different orchestrator entirely.

If your team is debating dbt versus Airflow as an either/or, check whether the real answer is "both, with a clear boundary between orchestration and transformation."

Common questions about dbt vs Apache Airflow

Can I use dbt and Apache Airflow together?

Yes, and this is actually the most common production pattern. Airflow handles orchestration of the full pipeline: triggering ingestion, waiting on upstream dependencies, and then calling dbt to run transformations inside the warehouse. The official dbt provider for Airflow makes this straightforward. You get Airflow's orchestration power and dbt's SQL transformation ergonomics without having to choose between them.

What does it actually cost to run Apache Airflow in production?

The software is free under Apache 2.0, but production infrastructure is not free. Self-hosted Airflow requires a PostgreSQL database, a message broker if you use CeleryExecutor, and worker machines plus engineering time to maintain all of it. Managed options remove that burden at a real cost: Google Cloud Composer moved to consumption-based pricing in 2025, billed by Data Compute Unit hours rather than a flat rate, landing around $300/month for a minimal setup and $500-1,500/month in production. If you see a flat per-hour Composer figure quoted anywhere, it predates that change. Factor in 2 to 4 hours per week of engineering time for self-hosted deployments.

Is dbt only for SQL or can it run Python?

dbt added Python model support via dbt-py for warehouses that support it, including Snowflake and Databricks. However, Python models in dbt are still executed inside the warehouse as Snowpark or PySpark jobs, not on your local machine or a general compute environment. dbt is fundamentally warehouse-centric. If you need Python running outside the warehouse, orchestrating APIs or file systems, you need Airflow or a similar orchestrator.

How long does it take to get Apache Airflow running in production?

A local Airflow install with LocalExecutor takes 30 minutes. A production-grade deployment with CeleryExecutor, PostgreSQL metadata database, Redis broker, and at least two worker nodes takes an experienced engineer 1 to 2 days. A managed deployment on Cloud Composer or MWAA takes 2 to 4 hours of configuration. The gap between local and production-ready is one of the most common sources of Airflow pain for teams new to it.

Which tool has better data lineage and documentation features?

dbt wins this comparison decisively. dbt automatically generates a visual DAG of all model dependencies, a browsable data catalog with column-level documentation, and a lineage graph you can share with stakeholders, all from your SQL and YAML files. Airflow's lineage support has improved with OpenLineage integration but requires additional tooling to reach the same level of visibility that dbt provides out of the box.

Is Airflow 3.0 worth upgrading to if we're already on 2.x?

For most teams, yes. DAG versioning alone fixes workflow drift, a real production bug class where a mid-run DAG deployment caused inconsistent behavior between task instances. The task-database-isolation change is a genuine security improvement too, though it can break DAGs that relied on direct database access as an (unsupported) workaround. Review your DAGs for direct ORM or session access to Airflow's internal models before upgrading; that's the most likely source of breakage.