# 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-temporal.md) · [Tidebase vs Inngest](tidebase-vs-inngest.md)