dbt build Is a Black Box in Airflow
dbt already models your pipeline as a graph — running it as one Airflow task throws that graph away right when you need it most.
Turn a dbt project into a real Airflow task graph with Cosmos — a task per model, selectors, state-aware runs, tests, and CI.
dbt already models your pipeline as a graph — running it as one Airflow task throws that graph away right when you need it most.
The simplest way to run dbt from Airflow is a shell command in a task — build it honestly, because it's the baseline everything better is measured against.
Astronomer Cosmos parses your dbt project and renders every model and test as a real Airflow task, wired in dbt's own dependency order.
One dbt project, many purpose-built DAGs — RenderConfig picks which nodes become Airflow tasks using dbt's own selector syntax.
Once the bookshop project grows, rebuilding every model on every run is waste — dbt's state comparison lets you build only what a change actually touched, if you get the manifest plumbing right.
A scheduled DAG that runs dbt isn't production yet — production is what you add after it works: legible test failures, warn-severity signals that don't fail loud, surgical retries that won't double-load, real observability off run_results.json, and CI that catches a bad model before it merges.
Load modes, manifests, partial parsing, invocation modes, operator args, and why scheduler parse cost is the hidden price of task-per-model dbt.
LOCAL, VIRTUALENV, DOCKER, KUBERNETES, EKS, ECS, Cloud Run, and the practical question of how code and credentials reach the worker.
How Cosmos emits Airflow assets for dbt models, how data-aware scheduling bridges tools, and where OpenLineage fits.
The retry and catchup hazards of stateful dbt models, full-refresh decisions, and data-interval-aware incremental patterns.
Cosmos versus dbt Cloud jobs and hand-rolled commands, plus target mapping, version pinning, and secrets across dev, CI, and prod.