Skip to main content

BPMN vs. Airflow / Prefect / Dagster: Process or DAG?

· 7 min read
Richard Bízik
Richard Bízik
Founder of QuantumBPM

A question that comes up surprisingly often: "we're picking a workflow tool — should we use Airflow, Prefect, or a BPMN engine?" The fact that it's even a question is interesting, because the three tools are genuinely solving different problems. The confusion comes from the shared word "workflow", which has been overloaded into uselessness.

Short answer: Airflow, Prefect, and Dagster are DAG-based data orchestrators. BPMN engines are business-process engines. They look similar from far away and feel completely different up close. This post is about the difference and how to pick.

The shape of the problem matters​

The cleanest way to tell these tools apart is to look at the shape of what each one models.

A DAG-based orchestrator like Airflow, Prefect, or Dagster models a directed acyclic graph of tasks, run on a schedule (or in response to a trigger). The classic example: an ETL pipeline. "At 02:00 every day, extract from these sources, transform, load into the warehouse, run dbt, send a Slack notification." Each task is a unit of code. The DAG is the dependency graph between them. The scheduler runs the right tasks in the right order at the right time.

A BPMN engine models a business process. The classic example: an order fulfilment flow. "When an order arrives, evaluate it. If it's flagged for review, send it to a human. Charge the customer. If charging fails three times, escalate. Ship it." Each step is a typed BPMN element. The diagram is the spec. The engine runs one instance per real-world event (per order, per claim, per onboarding).

The differences cascade from there.

Five concrete differences​

1. Cadence​

DAG orchestrators are schedule-shaped. The first-class concept is "this DAG runs every day at 02:00", and most of the platform is built around that — backfills, catchup runs, freshness SLAs, schedule overlap handling.

BPMN engines are event-shaped. The first-class concept is "an instance starts when an order arrives". Schedules exist (timer start events) but they're not the centre of gravity. Most instances are triggered by external messages, signals, or API calls.

If your problem is "do this batch on a schedule", DAG. If your problem is "react to this event with a multi-step flow", BPMN.

2. Instance lifetime​

A DAG run typically lives for the length of a single execution — minutes to hours. When it finishes, it's done. You query its history for debugging.

A BPMN instance routinely lives for days to weeks, because business processes do. An onboarding flow might spend two business days waiting for a document. A claims flow might spend a month in adjudication. Long-lived stateful instances with a current position, accumulated variables, and active timers are the normal mode of operation, not the exception.

3. Humans in the loop​

DAG orchestrators don't really model humans. You can fake a human approval with a sensor task that polls a database for a flag — and people do — but it's an awkward fit.

BPMN has user tasks as a first-class element. The engine holds a token until a person claims and completes the task. Assignment, reassignment, and escalation are all spec-defined. The task list integrates into your own UI via API. Half of business processes have a human step somewhere. That's why BPMN was designed around it.

4. Error and compensation semantics​

DAG orchestrators model failure as task retry plus on-failure callbacks. That covers most data-pipeline cases: a task failed, retry it, or alert if retries exhausted.

BPMN models failure as a layered set of concepts:

  • Errors with named types, caught at boundary events or in event sub-processes, traversing scope hierarchies (an error inside a sub-process bubbles up until it's caught).
  • Escalations that, unlike errors, can be non-interrupting — work continues while someone is alerted.
  • Compensation — the formal mechanism for undoing work that already succeeded when something later in the process fails. You don't "retry" a charge that already settled. You compensate it with a refund.

If your domain has the shape "we sometimes have to undo earlier work because something later went wrong", you want compensation, and BPMN is the spec that defines it.

5. Who owns the diagram​

A DAG is owned by engineers. It's Python (in Airflow, Prefect, Dagster), reviewed as code, and changed via PR.

A BPMN process is owned by the business. The diagram is the contract between engineering and the people who actually own the work — product, ops, compliance. It's reviewed by them, signed off by them, and audited by them. The XML serialisation is for the engine. The visual diagram is for the conversation.

This is the deepest difference, and it's the one that determines whether BPMN or a DAG orchestrator is right: who needs to read, change, and sign off this thing?

When a DAG orchestrator is the right answer​

Use Airflow, Prefect, or Dagster when:

  • The work is data-shaped — ETL, ingestion, dbt orchestration, ML training pipelines, reporting jobs.
  • The cadence is scheduled or pipeline-triggered, not driven by external business events.
  • The audience is engineers — data engineers, ML engineers, analytics engineers — not the business.
  • Per-run lifetime is bounded and short (minutes to hours).
  • The state model that matters is dataset freshness and lineage, not "where is this individual order in its lifecycle".

For these cases a BPMN engine is the wrong shape. Don't use one.

When a BPMN engine is the right answer​

Use a BPMN engine when:

  • The work is business-process-shaped — onboarding, claims, approvals, fulfilment, KYC, case management, underwriting.
  • Each instance corresponds to a real-world event (an order, a claim, a customer) and lives for as long as that event takes to resolve.
  • Humans are part of the flow — claiming, approving, completing tasks.
  • Audit, compliance, and governance are non-negotiable requirements, not nice-to-haves.
  • The diagram needs to be readable by non-engineers, who will review and sign off changes.

These are not data-pipeline characteristics. They're business-process characteristics. Different shape, different tool.

The boring answer: most large orgs need both​

A retailer running data pipelines for analytics and an order-fulfilment process for live transactions needs both — Airflow for the warehouse jobs, a BPMN engine for the order flow. They don't compete. They don't even sit in the same plane.

The mistake is forcing one shape into the other:

  • A DAG of "wait for human approval" tasks is a bad BPMN process.
  • A BPMN process of "extract, transform, load" steps is a bad data pipeline.

Match the tool to the shape and the rest is straightforward.

How QuantumBPM fits​

QuantumBPM is a BPMN+DMN platform — squarely in the business-process camp. We're not trying to be Airflow's replacement. We don't ship dataset lineage, schedule catchup, or the data-engineering-shaped tooling those platforms exist to provide. We do ship:

  • BPMN 2.0 process modelling and execution — events, tasks, gateways, scopes, compensation, multi-instance.
  • DMN 1.5 decision modelling — for the rules a business-rule task evaluates inside a process.
  • A web modeler, operational UI, and replay scrubber — for non-engineers who own the model.
  • Built on Temporal — durable execution under the BPMN layer.

If your problem is data orchestration, pick one of the three orchestrators above. If your problem is business processes, the comparison page covers how QuantumBPM stacks up against Camunda and other BPMN engines.

Where to go from here​