TL;DR — Airflow-style orchestration models ML pipelines as sequences of tasks that ran successfully, which is the wrong unit of abstraction for retraining, drift-triggered runs, and versioned artifacts. Asset-centric orchestration — treating datasets, features, and models as first-class, versioned objects with freshness contracts — matches how ML dependency graphs actually behave. The fix isn't picking Dagster over Airflow; it's changing what you orchestrate around.
Every orchestrator you've used was designed to answer one question: did task B run after task A succeeded? Airflow made that question extremely reliable. Cron made it explicit. Dagster, Prefect, and their peers all inherited the same core primitive: a directed graph of tasks, triggered on a schedule or a sensor, executed in order.
That primitive is correct for ETL. It is subtly wrong for ML.
The Assumption Baked Into Every DAG
Task-based orchestration assumes two things. First, that "ran successfully" is the meaningful state to track. Second, that dependencies are about execution order, not about data state. Both assumptions hold for a nightly report: extract, transform, load, done. Nobody asks whether yesterday's extract is "stale" in some semantic sense — it either ran or it didn't.
