Traditional orchestrators like Airflow define what tasks to run and in what order. The orchestrator doesn’t know what data those tasks produce. A successful task run means the code executed without errors — it says nothing about whether the data is correct, fresh, or even present. The orchestrator tracks execution state, not data state.
Asset-centric orchestration flips this. You define what data should exist and how to produce it. Each asset is a persistent data object — a BigQuery table, a GCS file, a dbt model — with a function that creates or updates it. The orchestrator tracks when each asset was last materialized, whether it’s fresh, and whether its upstream dependencies have changed since the last materialization.
Dagster is the clearest implementation of this model. Its core abstraction is the Software-Defined Asset, and every other concept in the platform — schedules, sensors, freshness policies — operates in terms of assets rather than tasks.
Why the Distinction Matters
The difference between task-based and asset-based orchestration shows up most clearly in debugging and monitoring scenarios.
Debugging
In a task-based system, “the pipeline succeeded at 8 AM” tells you tasks ran. It doesn’t tell you:
- Did the upstream data actually arrive before the transformation ran?
- Is the
mrt__finance__revenuetable current? - Did all upstream dependencies complete first, or did the task run against stale inputs?
You have to reconstruct the answers from logs, timestamps, and manual investigation. The orchestrator ran your code successfully; whether the resulting data is correct is your problem.
In an asset-centric system, you can directly ask: “Is mrt__finance__revenue current? When was it last materialized? Did all upstream assets complete first?” The system knows the answers because it tracks data state, not just execution state. The Dagster UI shows health indicators on every asset — materialized, stale, failed, fresh — so you can assess data health at a glance without reading logs.
Monitoring
Task-based monitoring answers: “Did the 6 AM job succeed?” Asset-based monitoring answers: “Is the data fresh enough for its consumers?” These are fundamentally different questions.
A pipeline might run on time every morning but consistently process data that’s already 4 hours stale because the upstream source was late. Task-based monitoring reports green. Asset-based freshness tracking reports that the data doesn’t meet its freshness SLA, even though the execution was technically successful.
Pipeline design
In task-based orchestration, you define a DAG of operations: “run task A, then task B, then task C.” The dependency is between operations, and the data they produce is a side effect that the orchestrator doesn’t see.
In asset-based orchestration, you define a graph of data objects: “asset X depends on asset Y, which depends on asset Z.” The operations that produce each asset are attached to the asset itself. The dependency graph is between data, not between code execution. This is a natural fit for analytics engineers who already think in terms of tables, models, and ref() dependencies.
The Natural Fit for dbt
If you work with dbt, you’re already doing asset-centric thinking without calling it that. Every dbt model produces a table (an asset). Every ref() call declares a dependency between assets. Every dbt build materializes assets in dependency order.
The gap is that dbt’s built-in scheduler (dbt Cloud) and most external orchestrators (Airflow, Cloud Run cron, Cloud Workflows) still think in tasks. They run dbt build as a task and report success or failure at the task level. They don’t know which individual models materialized, which are stale, or which have failing tests.
Dagster closes this gap. The dagster-dbt integration reads your manifest.json and creates one Dagster asset per dbt model. Your ref() calls become edges in the Dagster asset graph. Each model gets individual materialization tracking, freshness history, and quality checks from your dbt tests. The orchestrator finally sees what dbt has always been building: not tasks, but data assets.
Task-Based vs. Asset-Based: A Comparison
| Aspect | Task-based (Airflow, cron) | Asset-based (Dagster) |
|---|---|---|
| Core abstraction | Task (a unit of code execution) | Asset (a persistent data object) |
| Dependency graph | Between operations | Between data objects |
| ”Success” means | Code ran without errors | Data is current and correct |
| Monitoring | Execution timestamps, task status | Freshness, materialization history, health badges |
| Debugging | Read logs, correlate timestamps | Click an asset, see its full state and lineage |
| dbt fit | Runs dbt build as a single task | Each dbt model is a tracked asset |
| Selective re-execution | Re-run the failed task | Re-materialize the failed asset and its downstreams |
When Task-Based Is Still Fine
Asset-centric orchestration adds conceptual overhead. If your pipeline is “cron triggers dbt build, dbt writes to BigQuery, BI tool reads BigQuery,” a Cloud Run job on a cron trigger handles it well. The data state is simple enough that you can infer it from execution timestamps.
The asset model earns its complexity when:
- Multiple systems need to coordinate (ingestion, transformation, Python processing, BI refresh)
- Data freshness is a business requirement with SLAs, not just an assumption
- You need to re-materialize individual assets without re-running everything
- Cross-system lineage matters for debugging and impact analysis
The Dagster vs dbt Cloud comparison and the GCP orchestration decision framework cover the practical decision of when to adopt an asset-centric orchestrator versus simpler alternatives.
The Broader Trend
Dagster isn’t alone in recognizing this shift. Airflow 3.0 added its own @asset decorator, signaling that even the most established task-based orchestrator sees the value of asset awareness. The difference is that Dagster was built asset-first from the ground up, while Airflow is grafting asset concepts onto a task-based foundation. Whether that matters practically depends on how deeply you want asset semantics to permeate your orchestration layer.
The asset-centric model has moved from niche to common in 2026 orchestration tool evaluations, particularly for teams with data freshness SLAs.