Hatchet vs Temporal

Overview

Hatchet and Temporal are both platforms that enable developers to write durable workflows. These are workflows whose intermediate state is persisted, which means that if your worker crashes or fails halfway through a workflow, it automatically picks up where it left off. This can be particularly useful for AI agents, long-running jobs, or business-critical workflows. For example, here’s the same workflow, implemented in both Temporal and Hatchet (this workflow is implemented in Python, but both platforms support many different SDK languages):

@hatchet.task()
async def validate_order(_i, _c) -> dict[str, bool]:
  return {"valid": True}

@hatchet.task()
async def charge_order(_i, _c) -> dict[str, bool]:
  return {"charged": True}

@hatchet.task()
async def fulfill_order(_i, _c) -> dict[str, bool]:
  return {"fulfilled": True}

@hatchet.durable_task()
async def durable_task(input: EmptyModel, ctx: DurableContext) -> dict[str, bool]:
  await validate_order.aio_run()
  await charge_order.aio_run()
  return await fulfill_order.aio_run()

@activity.defn
async def validate_order() -> dict[str, bool]:
  return {"valid": True}

@activity.defn
async def charge_order() -> dict[str, bool]:
  return {"charged": True}

@activity.defn
async def fulfill_order() -> dict[str, bool]:
  return {"fulfilled": True}

@workflow.defn
class ProcessOrderWorkflow:
  @workflow.run
  async def run(self) -> dict[str, bool]:
      await workflow.execute_activity(validate_order)
      await workflow.execute_activity(charge_order)
      return await workflow.execute_activity(fulfill_order)

However, there are some notable differences:

1. Hatchet’s approach is batteries-included: it provides a full observability layer, including an OpenTelemetry collector and log sink, alerting, a fully-featured UI, pub/sub and streaming support, and deep integrations for modern programming tools like Claude Code and Cursor.

2. Hatchet is much more flexible in how you build tasks and workflows. Hatchet lets you easily run low-latency, highly scalable one-off tasks along with more complex workflows when you need them. So while Hatchet has all the same features for durable execution, they are not the only type of workload supported on the platform.

3. Hatchet has a larger feature set for scaling your workload, such as multiple fairness strategies, rate limiting, and routing support.

Hatchet strikes the rare balance between reliability and flexibility—giving you durable, fault-tolerant task execution without locking you into rigid workflows.

Aaron BanninPaxAI

Observability

Hatchet aims to make it as easy as possible to answer the question: why did my workflow fail? To answer this question, developers need contextual logging, tracing and observability for every task which runs in the system. As a result, Hatchet bundles a log ingestor and OpenTelemetry collector by default, rather than requiring developers to spend weeks setting up integrations with third-party providers (although instrumenting these yourself is very much possible, see here).

Flexibility

The most common starting point for a background job is to run a one-off task, such as sending a welcome email to a new user. In many applications, these types of jobs are the majority of your background processing. Hatchet makes this really simple by providing tasks as a top-level primitive.

However, with Temporal, these types of single-step or two-step workflows require you to write a Temporal workflow, which is overkill for simple queue use-cases. Beyond being overkill, durable execution comes with tradeoffs: it imposes strict limits on how you version and update your workflows. For more information, see our guide on how to think about durable execution.

Massively Parallel Workloads

For use-cases like large-scale data ingestion, you often need to run a large number of tasks in parallel. Hatchet is optimized for this type of workload: in particular, you can configure per-worker slot control so workers only accept the amount of work that they can handle. Additionally, features like rate limiting, multiple fairness strategies, and routing support allow you to distribute load among workers to process large batches of data.

Unlike Temporal, Hatchet does not place any limit on the total number of spawned tasks from a durable workflow. Temporal caps the number of pending child workflows and activities per run—the default is 51,200, set by the NumPendingChildExecutionsLimitError and related dynamic config values on the server.

Pricing

Hatchet and Temporal count work in a similar way: a workflow and each task or activity therein are billed as a unit. The differences are cost and retries. On Hatchet Cloud, your first 1M task runs and 1M events each month are free, then it’s $30 per million runs and $5 per million events, and retries aren’t billed. Temporal Cloud charges $50 per million actions from the first one, plus a 10% support fee, and bills retries, timers, signals, heartbeats, and other operations as separate actions.

Here’s a comparison of a sample workflow’s monthly costs. The example workflow represents an agentic loop running 10 child tasks, with each step set up as its own task or activity following each product’s docs. That works out to 11 runs per workflow on Hatchet and 11 actions on Temporal.

Why is Hatchet cheaper than Temporal?

We’ve spent two years obsessing over performance. Faster code means less load on the database, fewer spikes, and fewer machines. That’s what makes Hatchet more reliable, and it’s also what makes it cheaper. You can read more in our pricing announcement.

Full comparison

Hatchet aims to provide a full set of tools for background processing, which includes but is not limited to durable execution. Here’s a full list of features for comparison: