Orchestrators in 2026, the gap is closing from both sides

For years the orchestrator choice was a proxy war: tasks (Airflow's world) against assets (Dagster's). The 2026 releases read like both sides conceding the other had a point.

Airflow 3 has been shipping the ideas its critics used against it. Airflow 3.1 (September 2025) made human-approval steps a first-class primitive; 3.2 (April 2026) added asset partitioning, letting downstream DAGs trigger on a slice of an asset instead of the whole thing, which Dagster users will recognize as their pitch from three years ago, plus multi-team isolation in one deployment. Meanwhile Dagster's 1.13 line made its Components model GA and, notably, moved its Solo and Starter cloud plans to pay-as-you-go pricing from May 2026. Usage pricing on orchestration is worth watching skeptically: a credit per materialization is a bill that grows with exactly the behavior the asset model encourages.

how to actually choose

The comparison pieces are converging on the same guidance we would give. An existing Airflow estate, the widest hiring pool, or a plugin dependency: stay, because 3.x removed the reasons to flee. Greenfield, dbt-centric, and you think in tables rather than tasks: Dagster's developer experience remains genuinely better, and Components lowered its learning curve.

the pricing models deserve their own review

Orchestration pricing has quietly become the most interesting part of the category, because the models now encode opposing theories of what an orchestrator is. Seat and instance pricing treats it as infrastructure: a fixed cost for a thing that runs, predictable to the point of boredom, which is what finance wants from plumbing. Usage pricing treats it as a platform: the bill scales with materializations, which is to say with success, which is to say with exactly the fine-grained asset graph the product's own best practices recommend. Follow the incentive to its end and the pricing page starts editing your DAG: teams on per-materialization billing discover coarser assets, batched partitions and a sudden interest in "do we need this model hourly", none of which appears in the architecture docs.

Our advice is unglamorous. Model next year's bill from this year's event counts under both schemes before choosing, and ask the usage vendor one question in writing: what happens to the invoice when a backfill replays eighteen months of partitions. The answer, and the speed of the answer, tells you most of what the reference calls will not.

what neither camp fixes

The failure mode we see most in the field is not orchestrator choice but orchestrator sprawl: Airflow for the legacy estate, Dagster for the new team, a vendor scheduler inside the transformation tool, and cron on a forgotten VM holding the single job that feeds the CFO's favorite number. Every additional scheduler is a place where the on-call rotation loses the plot, because lineage tools stop at the border of the system that scheduled the run. Consolidation is worth more than selection. One orchestrator with a mediocre developer experience beats three orchestrators with excellent ones, and the migration that matters is usually not Airflow to Dagster but everything-else to anything-singular.

The counting exercise is worth an hour of anyone's time. List every system in the estate that can start a job on a schedule or a trigger: the orchestrator, the transformation tool's hosted scheduler, the warehouse's native tasks, the BI tool's extract refreshes, the ingestion vendor's sync timer, and whatever cron survived the last three platform migrations. Six is a common answer. Each one owns a piece of the morning, none of them can see the others, and the daily data landing is therefore a relay race between runners who have never met. When the 07:00 dashboard is late, the investigation tours all six, in sequence, at exactly the hour the organization is watching. Teams score this as an incident-response problem; it is an architecture problem wearing a pager.

The practical consolidation order, for what it is worth: kill the forgotten crons first (they are the ones without logs), move the BI refreshes to triggers fired by the pipeline that actually lands the data, and leave the transformation scheduler for last, because it is the one most likely to become the center of gravity anyway.

verdict

Airflow for institutions, Dagster for greenfield conviction, and either beats the in-house cron empire someone calls "our framework". Consolidate before you compare: an estate with one scheduler and the wrong logo on it is in better shape than an estate with the right logo and five stowaways. Watch the usage-pricing experiment from a safe distance until a few backfill invoices become public knowledge, and reread your own DAG counts before believing anyone's total cost math, including ours. The interesting story remains the convergence itself: when both camps ship the other's roadmap, the war is over and the procurement question is just pricing model and hiring pool.