The dagster-dbt integration reads a dbt project’s manifest.json and maps every model to a tracked Dagster asset with automatic lineage, freshness monitoring, quality checks, and CI/CD branch previews. This hub connects the individual notes that cover the integration in depth.
The Core Mapping
Dagster-dbt Asset Mapping covers the foundation: how manifest.json becomes a Dagster asset graph, the @dbt_assets decorator, DagsterDbtTranslator customization (custom keys, groups, tags, owner metadata from dbt meta), filtering which models become assets, and the two project setup paths (Components vs traditional).
The mapping is the prerequisite for everything else in the integration.
Quality Monitoring
Dagster Asset Checks from dbt Tests explains how Dagster 1.7+ automatically converts every dbt test (not_null, unique, accepted_values, custom tests, dbt-expectations) into an asset check. Severity mapping (error = blocking, warn = non-blocking) carries over from dbt configuration. The result is one UI for both execution and quality.
This connects to the broader dbt Testing Taxonomy and Elementary for dbt notes — Dagster surfaces all of these testing layers in a unified view.
Scheduling and Freshness
Dagster Freshness Policies and Scheduling covers asset-level freshness tracking (not just execution timestamps), schedule building from dbt selection syntax, event-driven sensors for cross-system coordination, and automation conditions. This is where Dagster differs most from simpler orchestrators like Cloud Run Jobs or Cloud Workflows.
CI/CD and Deployment
Dagster Branch Deployments for dbt describes ephemeral preview environments on PR, state-based selection (state:modified behavior), partitioned execution with dbt incremental models, and selective materializations for ad-hoc operations. Branch deployments provide visual graph diffing that goes beyond code-level PR review.
The Decision
Dagster vs dbt Cloud Orchestration provides the comparison: what dbt Cloud cannot do (non-dbt orchestration, cross-system dependencies, partitioned execution, full-stack lineage), the cost math ($10-100/month Dagster+ vs $100-300/month dbt Cloud for small teams), and the vendor independence argument after the October 2025 Fivetran-dbt Labs merger.
How This Relates to GCP Orchestration
The dbt Orchestration Decision Framework for GCP covers GCP-native options (Cloud Run Jobs, Cloud Workflows, Cloud Composer). Dagster is a separate axis in the orchestration landscape — it’s not GCP-native, but it provides capabilities (asset-level freshness, cross-system lineage, Python-first orchestration) that GCP-native tools don’t. Teams running dbt on GCP might use:
- Cloud Run Jobs for simple cron-triggered dbt execution (cheapest, simplest)
- Dagster for asset-aware orchestration with cross-system dependencies (mid-range cost, most capability for dbt specifically)
- Cloud Composer for enterprise Airflow-based orchestration (highest cost, broadest ecosystem)
The choice depends on whether your orchestration needs extend beyond “run dbt on a schedule.”