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