dbt vs Airflow: Different Jobs, Often Used Together

Quick answer: dbt and Airflow are not competitors. dbt, whether Core or Cloud, builds and tests SQL transformations inside your warehouse. Apache Airflow schedules and monitors workflows that span systems: extracts, file transfers, API calls, ML jobs, and dbt runs. Use dbt alone, scheduled by dbt Cloud or a simple cron job, when the whole workflow lives in the warehouse. Add Airflow when the dbt run has to wait for, or trigger, work outside it.

dbt Core vs dbt Cloud vs Airflow at a glance

Three ways to run dbt from Airflow

• Shell out: a BashOperator runs dbt build. Simple, but the whole project is one Airflow task.
• Astronomer Cosmos: renders each dbt model as an Airflow task, so you get per-model retries and visibility.
• Trigger dbt Cloud: the dbt Cloud provider's DbtCloudRunJobOperator starts a dbt Cloud job and waits for it, keeping model ordering inside dbt.

Use dbt Cloud when the workflow is mainly SQL models, tests, documentation, and deployment in a supported warehouse. Use Airflow when the dependency graph extends beyond that boundary. Many teams use both.

The ownership test

Ask who should debug the workflow when it fails. An analytics team can usually own a dbt Cloud job without operating scheduler infrastructure. Airflow gives a platform or data engineering team more control, along with responsibility for the scheduler, metadata database, workers, deployment, upgrades, and alerts.

The tool boundary should match the team boundary:

• dbt owns model dependencies, SQL transformations, model tests, and generated documentation.
• Airflow owns dependencies between systems, such as waiting for an extract, calling a service, starting a Spark job, and triggering dbt.

When dbt Cloud is enough

Choose dbt Cloud when data already lands in the warehouse and the remaining work is transformation. Its managed jobs, environment configuration, IDE, documentation hosting, and platform integrations reduce the amount of scheduler infrastructure an analytics team must maintain.

Check plan-specific features and current adapter support before deciding. Build one representative job with the deployment, access, and observability requirements you expect in production.

When Airflow is necessary

Choose Airflow when a DAG must coordinate work across several systems or requires custom Python control flow. Examples include:

• Extracting from an API before warehouse models run.
• Waiting for several external files with different arrival rules.
• Starting container, Spark, or ML workloads.
• Coordinating data movement between clouds or databases.
• Applying retry and alert policies to non-dbt tasks.

Airflow can also run SQL directly, but putting every model in a separate operator often recreates dependency logic that dbt already manages.

How to use both without duplicating the graph

A clean combined workflow looks like this:

1. Airflow confirms that required upstream data arrived.
2. Airflow triggers one intentional dbt Cloud job or selection.
3. dbt resolves model order and runs the selected transformations and tests.
4. Airflow handles downstream work outside dbt after the job succeeds.

Pass a run identifier or logical date across the boundary so logs can be correlated. Decide which system sends the final alert. Two schedulers retrying the same failure can create duplicate work or confusing incidents.

Failure cases to design before launch

• The upstream task succeeds but delivers incomplete data.
• An Airflow retry repeats a non-idempotent API or file operation.
• A dbt job passes while a freshness check was excluded.
• State-based selection skips a model even though source data changed.
• Airflow and dbt Cloud both schedule the same production job.
• Ownership is unclear because alerts contain links to both systems but no runbook.

Decision summary

Pick dbt Cloud for a managed analytics transformation workflow. Pick Airflow for programmable orchestration across systems. Use both when the boundary is explicit and each dependency graph has one owner.

Verify current behavior in the official dbt jobs documentation and Airflow architecture overview.

Primary sources and further reading

The implementation details and product behavior in this guide were checked against these primary references:

• apache-airflow-providers-dbt-cloud — Apache Airflow
• Astronomer Cosmos — Astronomer