Dagster

Dagster is the modern, asset-oriented workflow orchestrator. Created by Nick Schrock in 2018, it reframes orchestration around data assets rather than tasks and is the recommended choice for new data platforms.

@asset
def orders():
    return read_from_source()

@asset
def daily_revenue(orders):
    return orders.groupby("date").sum()

This sounds like a syntactic difference but it has deep consequences. Lineage is automatic — you don't bolt on a separate catalog. Backfills are asset-aware — "rebuild this table for the last 30 days" is a first-class operation. Partitioning is built in — Dagster knows that orders has a date partition and that each day can be materialized independently. Data quality checks attach to assets, not to tasks, and can block downstream materialization if they fail.

What Dagster Got Right

The asset abstraction. This is the headline and it deserves the headline. After working in Dagster for a few weeks, going back to Airflow feels like writing assembly after writing Python. You stop thinking about "what runs" and start thinking about "what data exists."

dbt integration is best in class. Every dbt model becomes a Dagster asset automatically via load_assets_from_dbt_project. Dagster understands the dbt DAG, can run subsets of it, and unifies it with non-dbt assets in a single lineage graph. For teams whose center of gravity is dbt, this alone is a reason to use Dagster.

Local development actually works. dagster dev spins up the full UI, scheduler, and a working environment in one command. No metadata database to provision. No Docker compose file with seven services. You can iterate on a DAG the same way you iterate on a Python script.

Types and IO managers. Dagster lets you declare the type of an asset (a DataFrame, a Snowflake table, a Parquet file) and define IO managers that handle reading and writing. This means your @asset function returns a Pandas DataFrame and Dagster handles writing it to S3 / Snowflake / wherever — you stop manually writing boilerplate persistence code in every task.

The UI. The asset graph view is genuinely better than Airflow's. You see freshness, lineage, partitions, and run history in one place. You can click an asset and see its definition, its upstream dependencies, and its materialization history without leaving the screen.

What Dagster Hasn't Quite Cracked

Mindshare lags Airflow by an order of magnitude. Job listings overwhelmingly ask for Airflow. New hires need to learn Dagster from scratch. This is the single biggest reason teams stay on Airflow even when they prefer Dagster's design.

Migration from Airflow is painful. There's no automatic translator. You rewrite. Dagster has shipped tooling to make this easier (including some Airflow-compatibility shims) but in practice migrations are months-long projects. For brownfield environments, this often kills the conversation before it starts.

The asset model has a learning curve for people who think in tasks. Engineers coming from Airflow sometimes spend their first week trying to translate "tasks" 1:1 into "assets" and getting frustrated. The mental shift — "stop thinking about scripts, start thinking about tables" — takes a few weeks to internalize.

Open source vs. Dagster+ tension. As with most open-core companies, there are features (some auth, some advanced scheduling, the cloud-hosted plane) that live only in the paid product. This is fine and reasonable, but it's something to know going in.

Honest Take

Dagster is, technically, the better orchestrator. Almost every architectural choice the team made — assets over tasks, IO managers, types, partitioning — has aged well, and the gap relative to Airflow has only widened over time. For a brand-new data platform in 2026, Dagster is the recommended choice. For an existing Airflow environment with hundreds of DAGs, the migration cost usually outweighs the benefit, and the right move is to stay on Airflow (likely managed by Astronomer).