# Tidebase vs Temporal: do you need durable execution for an AI agent?

The short answer: **Temporal asks you to move execution into its worker model; Tidebase asks you to wrap functions you already have.** Different adoption cost for a smaller guarantee. If you're already all-in on Temporal, you don't need Tidebase.

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

**Temporal owns durable execution.** Your workflow code runs inside Temporal workers against the Temporal server (or Temporal Cloud). In exchange for adopting its programming model — deterministic workflow functions, activities, task queues, its deployment topology — you get true durable execution: a dead worker's workflow continues on another worker automatically.

**Tidebase does not execute your code.** Your app, worker, or job process keeps calling your LLMs, tools, and APIs directly. The SDK wraps your workflow function; a Postgres-backed server stores checkpoints, state, events, and gates around it. Since v0.5 Tidebase also owns re-invocation when you want it to: durable queues (pull workers or signed push webhooks), cron schedules, and a reconciler that requeues runs whose worker died — completed steps replay from checkpoints, so retries never re-pay for finished work.

## Side by side

| | Tidebase | Temporal |
|---|---|---|
| Executes your code | No — external checkpoint coordination | Yes — worker runtime |
| Guarantee | Completed steps never repeat on re-invocation | Workflow continues automatically after worker death |
| Adoption cost | Wrap existing functions in `run.step()` | Restructure into deterministic workflows + activities; run workers |
| Infrastructure | Your app + one server + Postgres | Temporal cluster (or Cloud) + workers |
| Determinism constraints on your code | None | Workflow code must be deterministic |
| Live run state for product UIs | Built in (`run.state`, SSE) | Build yourself (queries/signals) |
| Human approval gates | Built in, durable, exactly-once | Build with signals |
| Agent-specific features (fanout/join of subagents, state versioning/forking, token-cost ledger) | Built in | Build yourself on primitives |
| Maturity | Self-hosted alpha, opt-in auth | Battle-tested at large scale, production-grade |

## Choose Temporal if

- You need true automatic continuation — no part of your stack can be responsible for re-invoking work.
- You have long-lived, complex orchestrations (days/weeks, timers, sagas) beyond agent pipelines.
- You need production-grade multi-tenancy, auth, and operational tooling today.

## Choose Tidebase if

- You have an existing app or worker and want crash-safe resume without restructuring it around a workflow engine.
- Your pain is agent-shaped: "is it safe to rerun?", progress streaming to a product UI, human approval gates, subagent fanout, per-run token costs.
- You want everything in your own Postgres, self-hosted, Apache-2.0.

Repo: <https://github.com/BlueprintLabIO/tidebase> · See also: [Tidebase vs Inngest](tidebase-vs-inngest.md) · [Tidebase vs DBOS and Restate](tidebase-vs-dbos-restate.md)