Apache Airflow vs Dagster

Quick verdict

Apache Airflow is an Apache Software Foundation project for authoring, scheduling and monitoring workflows as DAGs (directed acyclic graphs) of tasks written in Python. Airflow 3.0 was first released on 22 April 2025; the current release is 3.3.2 (17 September 2026). Airflow 3 renamed the concept previously called a dataset to an asset: the Airflow documentation states "Changed in version 3.0: The concept was previously called 'Dataset'", and the upgrade guide maps airflow.datasets.Dataset to airflow.sdk.Asset. Airflow 2.x reached end of life on 22 April 2026.

Dagster, developed by Dagster Labs, describes itself on PyPI as "a cloud-native data pipeline orchestrator for the whole development lifecycle, with integrated lineage and observability, a declarative programming model". Its central abstraction is the software-defined asset: a Python function decorated with @dg.asset that produces a table, file or model, with dependencies between assets forming a lineage graph. Dagster also supports ops and jobs for task-style work. The current release is 1.13.25 (1 October 2026), supporting Python 3.10 to 3.14. Dagster+ is the vendor's hosted platform.

Both are orchestrators, not connector-based ingestion tools. For that pairing, see Apache Airflow vs Airbyte and Apache Airflow vs Fivetran.

Side by side

Key differences

Task-based DAGs versus software-defined assets

The same small pipeline (read some orders, compute a total, refresh daily at 06:00 UTC) shows the difference. In Airflow you describe steps: three tasks wired into a DAG. In Dagster you describe outputs: two assets, where order_total depends on raw_orders because it takes it as a function argument, and a schedule that materialises both. Both examples follow the official documentation and were syntax-checked with Python 3.14.

# Apache Airflow 3 (TaskFlow API, airflow.sdk)
import pendulum
from airflow.sdk import dag, task


@dag(
    schedule="0 6 * * *",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["orders"],
)
def daily_orders():
    @task(retries=2)
    def extract() -> list[dict]:
        return [{"id": 1, "amount": 120.0}, {"id": 2, "amount": 80.0}]

    @task()
    def transform(rows: list[dict]) -> float:
        return sum(r["amount"] for r in rows)

    @task()
    def load(total: float) -> None:
        print(f"Total order value: {total:.2f}")

    load(transform(extract()))


daily_orders()

# Dagster 1.13 (software-defined assets)
import dagster as dg


@dg.asset
def raw_orders() -> list[dict]:
    return [{"id": 1, "amount": 120.0}, {"id": 2, "amount": 80.0}]


@dg.asset
def order_total(raw_orders: list[dict]) -> float:
    total = sum(r["amount"] for r in raw_orders)
    print(f"Total order value: {total:.2f}")
    return total


daily_refresh = dg.ScheduleDefinition(
    name="daily_refresh",
    cron_schedule="0 6 * * *",
    target=[raw_orders, order_total],
)

defs = dg.Definitions(
    assets=[raw_orders, order_total],
    schedules=[daily_refresh],
)

In Dagster, values returned by assets are stored and loaded by I/O managers, so order_total receives raw_orders without you writing the hand-off; when an asset writes to a database itself (for example with CREATE TABLE ... AS SELECT), you declare the dependency with deps=[...] instead, and nothing is passed. Each asset has a materialisation history, so the UI can show when a table was last refreshed and from which run. In Airflow, values pass between tasks through XComs, and what a task produced is visible to the scheduler only if you declare it as an outlet asset.

Airflow 3 assets: how close does Airflow get?

Airflow 3 made assets more central. A producer task declares outlets=[asset], and a consumer DAG uses schedule=[asset] to run when the asset is updated; multiple assets combine with & and |. The documentation also describes an @asset decorator that creates an asset, a DAG and a task in one step, and AssetWatchers that turn external events into asset updates.

# Apache Airflow 3: asset-aware scheduling
import pendulum
from airflow.sdk import Asset, dag, task

orders_file = Asset("s3://example-bucket/orders.parquet")


@dag(schedule="@daily", start_date=pendulum.datetime(2026, 1, 1, tz="UTC"), catchup=False)
def produce_orders():
    @task(outlets=[orders_file])
    def write_orders() -> None:
        ...  # write the file

    write_orders()


@dag(schedule=[orders_file], start_date=pendulum.datetime(2026, 1, 1, tz="UTC"), catchup=False)
def report_orders():
    @task()
    def build_report() -> None:
        ...  # runs after orders_file is updated

    build_report()


produce_orders()
report_orders()

The difference that remains is emphasis. Airflow's documentation says it "makes no assumptions about the content or location of the data represented by the URI, and treats the URI like a string": an Airflow asset is a scheduling signal and lineage marker attached to tasks. In Dagster the asset is the unit you define, materialise, partition, check and automate, and the task is the means of producing it. Teams that already have many task-based DAGs can adopt Airflow assets gradually; teams starting from a data model may find Dagster's approach more direct.

Scheduling and automation

Airflow offers cron expressions, presets and custom timetables, asset-aware scheduling and event-driven scheduling through the REST API or AssetWatchers. In Airflow 3, catchup defaults to False, backfills are managed by the scheduler and can be launched from the UI, and SLAs were deprecated and replaced by Deadline Alerts.

Dagster documents several mechanisms: schedules (cron, run in UTC unless you set execution_timezone), sensors for external events, asset sensors, GraphQL triggers, and Declarative Automation, where each asset carries a condition such as dg.AutomationCondition.eager() (update when dependencies change) or dg.AutomationCondition.on_cron("@hourly"). The documentation notes that Declarative Automation needs the default automation condition sensor to be switched on in the UI.

UI and observability

Airflow 3's rewritten React UI centres on the Dags list and the Grid view, which its documentation calls "the primary interface for inspecting Dag runs and task states", plus a Graph view, task instance logs, an asset list and asset graph, and admin pages for connections, variables and pools. DAG versioning shows which code version a past run used.

Dagster's UI (served by dagster-webserver, started locally with dg dev) centres on assets: the asset lineage graph, materialisation history, and buttons to materialise selected assets, alongside runs, schedules and sensors. Dagster+ adds Insights for platform trends and cost, alerts to Slack, PagerDuty and email, an asset catalog with advanced search and column lineage, role-based access control and audit logs, and branch deployments for testing changes.

Deployment: self-hosted, managed Airflow or Dagster+

Self-hosted Airflow needs a scheduler, a Dag processor, an API server that also serves the UI, and a metadata database, usually PostgreSQL or MySQL, with workers and a triggerer as optional components. Managed Airflow is available from Astronomer (Astro Runtime 3.3-8 is based on Airflow 3.3.2), Amazon MWAA (newest listed version 3.3.1, plus MWAA Serverless, announced November 2025) and Google's Managed Service for Apache Airflow, previously known as Cloud Composer, which lists Airflow 3.3.1 builds.

Self-hosted Dagster runs a webserver, a single daemon for schedules, sensors and run queuing, and one or more code location servers, with SQLite run storage by default and PostgreSQL for production. Its documentation covers local deployment, running as a service, Kubernetes, Docker Compose, AWS and Google Cloud. Dagster+ comes in two forms: Serverless, where "your Dagster code executes in our environment", and Hybrid, where Dagster+ runs the control plane and you run the execution layer in your own infrastructure.

Pricing and licensing

Apache Airflow is free and open source under the Apache-2.0 licence. Managed services charge by usage. As one dated example, the Amazon MWAA pricing page listed USD 0.49 per hour for a small environment in US East (N. Virginia) in October 2026, with additional workers, schedulers, web servers and metadata storage billed separately. Astronomer bills deployments by the hour plus worker compute while tasks run; Google's Managed Service for Apache Airflow has its own usage-based pricing. Use each provider's calculator for an estimate.

Dagster open source is free under the Apache-2.0 licence. Dagster+ is billed by plan plus credits, where the pricing page defines a credit as "the sum of asset materializations and ops executed". As listed on dagster.io/pricing in October 2026: Solo is USD 10 per month for 1 user and 1 deployment, with credits at USD 0.040 each; Starter is USD 100 per month for up to 3 users with credits at USD 0.035; Pro is priced on request. Dagster+ Serverless compute is billed per minute on top. Solo and Starter have a 30-day free trial.

We describe pricing models only and do not estimate bills. Note that the two models scale with different things: MWAA and Astronomer with environment and worker hours, Dagster+ with the number of materialisations and op executions.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want to orchestrate existing Python scripts with native control flow and event-driven automations: look at Prefect; see Apache Airflow vs Prefect and Prefect vs Dagster.
• Your main need is copying data from SaaS applications and databases into a warehouse: a connector-based ingestion tool may be enough; see Apache Airflow vs Airbyte, Apache Airflow vs Fivetran and the best ETL tools guide.
• You have a handful of SQL jobs in one database: the database's own scheduler (SQL Server Agent, or pg_cron for PostgreSQL) may be enough. ETL vs data pipeline explains the terms.

Final recommendation

Frequently asked questions

Sources

• Apache Airflow release notes
• Apache Airflow: Upgrading to Airflow 3
• Apache Airflow: Assets
• Apache Airflow: Asset-aware scheduling
• Apache Airflow: Architecture overview
• Apache Airflow: UI overview
• Apache Airflow: Supported versions
• Dagster documentation: Quickstart
• Dagster documentation: Asset dependencies
• Dagster documentation: Automation
• Dagster documentation: Declarative Automation
• Dagster documentation: dbt integration
• Dagster documentation: OSS deployment architecture
• Dagster+ documentation
• Dagster+ pricing
• dagster on PyPI
• Amazon MWAA: Supported Airflow versions
• Amazon MWAA pricing
• Astronomer pricing
• Google Cloud: Managed Service for Apache Airflow versions

Checked October 2026.

How we research comparisons: our editorial method.