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 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