Temporal, Argo Workflows, Apache Airflow, Prefect, Dagster

TL;DR#

Temporal, Argo Workflows, Airflow, Prefect, and Dagster are centralized orchestrators -- a coordinator schedules and monitors every step. Asya is a decentralized actor mesh where stateless handlers communicate through durable message queues and each message carries its own route. This gives Asya per-actor independent scaling (including to zero), fault isolation per step, and zero SDK lock-in -- at the cost of requiring Kubernetes.

Comparison Table#

Key Differences#

Choreography vs centralized orchestration#

Every orchestrator in this comparison runs a central scheduler or server that decides what executes next. Temporal replays workflow history. Airflow's scheduler triggers tasks. Argo submits pods according to a DAG spec. If the coordinator goes down, all pipelines stall.

Asya has no coordinator. Each envelope carries its own route (prev/curr/next), and each actor forwards the result to the next queue. A crashed actor affects only its own queue -- messages accumulate until replicas recover, while other actors continue independently. Global visibility requires aggregating per-actor metrics rather than querying a scheduler.

Per-actor scale-to-zero#

Airflow, Prefect, and Dagster require always-on scheduler/daemon processes. Temporal workers must poll continuously. Even Argo, which runs each step as a pod, keeps the workflow controller running permanently.

Asya scales each actor independently via KEDA based on queue depth -- including down to zero pods. A GPU inference actor on A100s costs nothing between batches. When traffic arrives, KEDA spins up pods in seconds -- particularly cost-effective for bursty AI/ML workloads where idle GPU time dominates cost.

No SDK, no determinism constraints#

Temporal requires workflow code to be deterministic -- no random calls, no direct I/O, no non-deterministic library usage. Airflow, Prefect, and Dagster require decorators and framework-specific constructs. Argo is the exception: any container image works.

Asya handlers are plain Python functions with a dict -> dict signature:

def score_image(payload: dict) -> dict:
    payload["score"] = model.predict(payload["image_url"])
    return payload

No decorators, no base classes, no determinism rules. Retry policies, timeouts, and scaling live in the AsyncActor manifest:

apiVersion: asya.sh/v1alpha1
kind: AsyncActor
metadata:
  name: score-image
spec:
  image: scoring:latest
  handler: handler.score_image
  scaling:
    minReplicaCount: 0
    maxReplicaCount: 10
  resiliency:
    actorTimeout: 120s
    policies:
      default:
        maxAttempts: 3
        backoff: exponential
        initialInterval: 2s
        maxInterval: 30s

Dynamic routing at runtime#

Airflow and Dagster define DAG structure at parse time -- the graph is static. Prefect allows runtime conditionals but within a single flow execution. Temporal supports dynamic branching through workflow code but requires deterministic replay.

Asya actors can rewrite the message route at runtime. An LLM judge can route high-confidence results directly to storage and low-confidence results to human review:

def judge(payload: dict):
    if payload["confidence"] > 0.9:
        yield "SET", ".route.next", ["store"]
    else:
        yield "SET", ".route.next", ["human-review"]
    yield payload

The route is data, not code structure. No DAG rebuild, no redeployment.

When to Use What#

Use 🎭 Asya when:

• You run on Kubernetes and need per-step independent scaling with scale-to-zero
• GPU and CPU steps must scale on different hardware profiles independently
• Multiple teams own different pipeline steps and deploy independently
• Workloads are bursty or latency-tolerant (seconds to minutes per step)
• You want zero SDK lock-in -- plain Python functions, no framework imports

Use Temporal when:

• You need exactly-once semantics and durable execution guarantees
• Complex state machines with compensation (sagas) span days or weeks
• Timer-based scheduling (cron, durable timers) is a first-class requirement
• Multi-language orchestration across Go, Java, Python, and TypeScript matters
• You need a mature Web UI with searchable execution history out of the box

Use Argo Workflows when:

• You need K8s-native DAG execution with per-step container isolation
• CI/CD pipelines or batch jobs are the primary use case
• Polyglot steps (any container image) with artifact passing between pods
• You already run Argo CD and want a unified Argo ecosystem

Use Apache Airflow when:

• Data engineering pipelines with scheduled batch processing (ETL/ELT)
• You need 1000+ community-maintained operators and provider integrations
• The team knows Airflow and the workload is primarily scheduled DAGs

Use Prefect when:

• You want Python-native workflow orchestration with minimal boilerplate
• Hybrid execution (cloud-managed + self-hosted workers) fits your model
• Dynamic, parameterized flows with runtime branching are common

Use Dagster when:

• Data assets and lineage tracking are central to your architecture
• Software-defined assets align with how your team thinks about data pipelines