# Tidebase vs Hatchet

The short answer: **both are Postgres-backed and open-source, but Hatchet is a task orchestrator — its engine dispatches work to workers connected over gRPC — while Tidebase is a checkpoint record your own code writes to over HTTP.** Hatchet schedules and routes execution; Tidebase makes whatever execution you already have resumable.

Tidebase is an open-source checkpoint layer for AI agents: wrap your steps, and failed runs resume from the last safe point — in your own Postgres, without moving execution into a new runtime.

## The structural difference

**Hatchet owns dispatch.** You register workflows on workers; the Hatchet engine assigns tasks to them, enforces concurrency and rate limits, runs DAGs and durable tasks, and supervises the fleet. It replaced "a queue plus glue code" with a real distributed task platform — workers are long-lived processes wired into the engine.

**Tidebase owns the record.** There is no engine-to-worker channel and no task assignment protocol: your function calls `run.step(...)` over HTTP when it does work, and Postgres remembers what completed. Queues and cron exist (since v0.5) for triggering — pull workers claim runs, or signed webhooks invoke your app — but the center of gravity is the replayable run record: checkpoints, the [replay contract](../replay-contract-is-it-safe-to-rerun.md) for side effects, gates, live state, and the per-run cost ledger.

## Side by side

| | Tidebase | Hatchet |
|---|---|---|
| Storage | Your Postgres | Postgres (its schema, its engine) |
| How work reaches your code | You invoke it; or pull-claim from queues / signed push webhooks | Engine dispatches to connected gRPC workers |
| Workflow model | Plain function with `run.step()` checkpoints | Tasks/DAGs/durable tasks registered on workers |
| Intra-task resume | Yes — steps replay from checkpoints | Durable tasks support replay-style semantics |
| Concurrency / rate control | Per-queue caps and rate limits | First-class, fine-grained (per-key concurrency, fairness) |
| Human approval gates | Built in, durable, exactly-once | Build with events/signals |
| Agent-shaped extras | Live state versions, fork/time-travel, fanout child runs, token ledger | General-purpose task platform |
| Protocol surface | HTTP + SSE | gRPC workers + API |
| Maturity | Self-hosted alpha, opt-in auth | Production deployments, hosted cloud available |

## Choose Hatchet if

- You're replacing a task queue at scale and want an engine to own assignment, fairness, and fleet supervision.
- You want fine-grained concurrency control (per-tenant keys, rate limits) as the headline feature.

## Choose Tidebase if

- You don't want an engine between your code and your work — your app/worker stays exactly as deployed today, and durability is a layer, not a migration.
- The run record matters as much as the running: you want checkpoints, gates, state history, and costs as rows you can join against your own tables.
- Your workloads are agent-shaped and you want the safety question — "it died at step 7, can I rerun?" — answered structurally.

The honest tradeoff: Hatchet's engine earns its complexity when dispatch itself is the hard problem. Tidebase deliberately doesn't solve fleet orchestration — it makes re-invocation safe and leaves running things to you.

Repo: <https://github.com/BlueprintLabIO/tidebase> · See also: [Tidebase vs Temporal](tidebase-vs-temporal.md)