# Tidebase vs Inngest

The short answer: **Inngest is an event-driven durable execution platform that invokes your functions for you; Tidebase is a checkpoint layer around functions your own infrastructure invokes.** They look similar at the API level (`step.run()` vs `run.step()`) but sit in different positions in your stack.

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

**Inngest owns invocation.** You define functions triggered by events; the Inngest platform (cloud or dev server) calls your endpoints, drives step execution, handles retries, throttling, and flow control. Your functions are invoked *by* Inngest.

**Tidebase owns the record and the trigger — never the runtime.** Since v0.5 it ships durable queues and cron: pull workers claim jobs, or Tidebase pushes signed invocation webhooks to your app. Your code still runs in your own processes with your own secrets. The remaining honest difference: Inngest hosts the orchestration platform; Tidebase is a single self-hosted server on your Postgres.

## Side by side

| | Tidebase | Inngest |
|---|---|---|
| Who invokes your function | Tidebase queues/cron (pull or signed push), or your own infra | Inngest platform, on events |
| Retries, throttling, concurrency control | Built in (backoff, dedupe, per-queue caps) | Built into the platform |
| Data location | Your Postgres, self-hosted | Inngest cloud (self-host option exists) |
| Live run state API for product UIs | Built in, with SSE + versioned history | Not a core primitive |
| Human approval gates | Built in, durable, exactly-once, webhook-deliverable | `waitForEvent` pattern |
| Subagent fanout with idempotent child runs | Built in | Compose with function invocation |
| Per-run token/cost ledger | Built in | Build yourself |
| Maturity | Self-hosted alpha, opt-in auth | Production-grade, hosted |

## Choose Inngest if

- You want a platform to own queueing, retries, and flow control so you don't run that infrastructure.
- Your workflows are naturally event-driven and you're comfortable with the platform invoking your endpoints.

## Choose Tidebase if

- You want queues/cron/durability in one self-hosted server on your Postgres, without your code running inside someone else's platform.
- You want run state, approval gates, and checkpoints in *your* Postgres next to your app's data.
- Your workloads are AI-agent-shaped and you want fanout, forking, and cost tracking as first-class primitives.

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