Tidebase vs DBOS and Restate
The short answer: DBOS and Restate embed durable execution into your application (a library/engine that owns how your functions run); Tidebase stays outside your execution path entirely — it records checkpoints and state around code that your own infrastructure invokes.
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
DBOS is a library that makes your application itself durable: decorated workflow functions checkpoint into Postgres, and the DBOS runtime inside your app handles recovery and resumption of pending workflows on restart.
Restate is a durable execution engine: a log-centric server that drives your handlers, journals every step, and replays them deterministically after failures — it owns invocation and retries.
Tidebase owns the record and (since v0.5) the trigger, but never the runtime. Your code calls out to a Postgres-backed server that records step completions, state versions, gates, and events — and its queues, cron schedules, and reconciler re-invoke your workflows after crashes (pull claims or signed push webhooks). Completed steps replay from checkpoints; the runtime, secrets, and deploy model stay entirely yours.
All three share the Postgres-respecting, self-hostable ethos. The difference is how much of your architecture they ask to own.
Side by side
| Tidebase | DBOS | Restate | |
|---|---|---|---|
| Where durability lives | External server + your Postgres | Library inside your app + Postgres | Restate engine (log) driving your handlers |
| Owns invocation/recovery | No — your infra or recovery webhooks | Yes — runtime resumes pending workflows | Yes — engine re-drives handlers |
| Determinism requirements | None (steps checkpoint results) | Workflow functions deterministic between steps | Handlers deterministic for replay |
| Agent primitives (gates, fanout run trees, state forking, cost ledger, Studio UI) | Built in | Build on primitives | Build on primitives |
| Live state API for product UIs | Built in (SSE + versions) | Build yourself | Build yourself |
| Maturity | Self-hosted alpha, opt-in auth | Production-grade | Production-grade |
Choose DBOS or Restate if
- You want automatic recovery with no part of your stack responsible for re-invocation.
- You’re building general backend workflows where deterministic replay is a fine constraint.
Choose Tidebase if
- You want zero change to how your code is invoked and deployed — wrap functions, keep your queue/cron.
- Your workloads are agent-shaped and you want approval gates, subagent fanout, state forking, and token-cost tracking out of the box, with a dashboard.
- You want the record of every run in your own Postgres with a UI your team (and your product) can read.
Repo: https://github.com/BlueprintLabIO/tidebase · See also: Tidebase vs Temporal · Tidebase vs Inngest