Temporal vs Restate vs Inngest vs DBOS: where the agent’s transcript lives

At a glance

Four projects, four genuinely different shapes — and the shape, not the feature list, is what you are buying.

Restate is written in Rust, ships as one binary, and records events in a distributed log built on a virtual-consensus design derived from Flexible Paxos, with SDKs for TypeScript, Python, Java/Kotlin, Go and Rust. Temporal came out of the team that built Cadence at Uber and is the oldest and most operationally proven of the four. Inngest is the only one where the correct answer to "what do we deploy" is nothing, and it is the only one shipping a first-party agent framework — AgentKit, with agents composed into networks, a router choosing who runs next, shared network state, and MCP servers as tools. DBOS is the only one that adds no infrastructure at all: decorate a function, and its checkpoints land in the Postgres you already operate.

The ceiling nobody plans for

In a conventional workflow — charge a card, send an email, update a row — durable state is a few kilobytes and nobody thinks about it again. An agent inverts that. Every turn appends a model response, and every tool call appends a result, and those results are the fat ones: a page of scraped HTML, a query returning four hundred rows, a file the agent read. If you journal them, the durable record grows roughly with the transcript, which grows roughly with the square of the step count once you account for re-sending.

The published numbers are worth memorising because they arrive as production incidents rather than as warnings:

• Temporal. A single payload warns at 256 KB and errors at 2 MB. Event history warns at 10,240 events or 10 MB, and the service terminates the workflow at the 51,201st event or 50 MB with a non-retryable error. There is also a 4 MB cap on a single Workflow Task transaction, which a workflow can hit by scheduling many modestly sized activities at once even though no individual payload was large.
• Inngest. Data returned by a step is capped at 4 MB, and total function run state cannot exceed 32 MB.
• Restate. No fixed per-run ceiling is published in the same way; version 1.5 added automatic payload compression as payloads approach the size limit, which particularly helps when running on AWS Lambda.
• DBOS. No engine ceiling, because the checkpoints are rows in your database. What you inherit instead is table growth, index bloat and a vacuum story.

Two conclusions follow, and the second one is the useful one. First, engine-enforced ceilings are not a defect — they are a forcing function that makes you externalise the transcript early, which you should be doing anyway. Second, and this is the part that decides architectures: store the transcript by reference from the first commit, whichever engine you pick. Write tool results and messages to object storage or a table, journal the key and a short summary, and the ceiling never becomes an event. Teams that journal payloads by value hit the wall at month six, and the migration is not a config change — it is a rewrite of every step signature in the codebase, performed under the pressure of runs that are already failing.

Where the model call is allowed to sit

Recovery mechanisms differ in a way that shows up as a constraint on your source code, not as a line in a comparison table. Temporal recovers by replaying workflow code against the recorded history, which is why workflow functions must be deterministic: no wall-clock reads, no unguarded randomness, no I/O. That is not a burden in itself — it is a well-understood discipline with a decade of tooling behind it — but for an agent it has a specific consequence. The model call is I/O, so it lives in an activity, and anything you wanted to do with a token stream cannot originate in workflow scope. Streaming to a user from a Temporal agent is a separate channel you build, not a return value you await.

Restate and Inngest journal instead of replaying your control flow in the same sense: you write ordinary functions and mark the durable steps, and a recovered run reads completed steps back from the journal. The discipline that remains is subtler and catches people anyway — a step's result has to serialise and has to stay stable, so a step that returns a live client object, a generator, or a value that embeds the current time will misbehave on the retry path rather than the happy path.

DBOS is the least invasive of the four: decorators on ordinary functions, checkpointing to Postgres, no separate service in the request path. The trade is that durability now shares a failure domain with your application and a capacity budget with your primary database. That is an excellent trade for a Python or TypeScript team already running Postgres, and a poor one for a workload whose durable state would double the size of an already-strained database.

All four are being wired into agent frameworks rather than competing with them: DBOS and Restate both document Pydantic AI integrations, Inngest ships AgentKit directly, and Temporal's pairing with graph-based orchestrators is the subject of its own deep dive. The durability layer is not your agent framework; it is the thing that survives underneath it.

Billing shape versus a loop that mints steps

The pricing question is not "what does it cost per month", it is "what does my program's shape do to the meter". An agent loop is unusually good at manufacturing the unit that gets billed.

Inngest bills per execution, where an execution is a function run plus each step inside it — a function with five step.run() calls consumes six. That is entirely reasonable for an event-driven workflow with a fixed shape. For an agent that runs until it decides to stop, the step count is a variable the model controls, and cost becomes a function of task difficulty in a way that is hard to forecast and easy to have a bad week with. The free tier is 50,000 step runs a month with paid plans starting around $20, so the arithmetic is easy to do in advance — do it with your p99 step count, not your median.

Temporal self-hosted is MIT-licensed and free in the sense that only the cluster costs money, which for many teams is the honest cheapest option and for others is a Cassandra or SQL persistence layer nobody wanted to own; Temporal Cloud converts that into a managed bill. DBOS is the outlier: the durable-execution layer is a library, so the marginal infrastructure cost of durability is the storage and load your checkpoints add to a database you were already paying for. Restate sits between them — one binary to run, or a managed offering.

Whichever you pick, the cost model that matters is the one in agent cost control: the model tokens dominate, and the durability layer's bill is a rounding error unless its unit happens to be the thing your loop generates without limit. On Inngest, it is.

When to pick which

What should not decide it: which one has a nicer diagram of retries, and which one your framework's tutorial happened to use. All four retry, all four resume, all four do timers and signals. The differences that survive contact with production are the three above — where the growth goes, what the recovery model asks of your code, and what the meter counts.

Further reading

On this wiki:

• Durable execution: LangGraph plus Temporal — the pairing pattern in depth.
• Durable state & resumability — what has to be checkpointed and why.
• Idempotency & retries — the half of this problem the engine does not solve for you.
• Scheduled & triggered agents — the workloads that force the decision.
• Agent cost control — why the step count is the number to forecast.

Project sources:

• Temporal payload and gRPC size limits and self-hosted defaults
• Inngest usage limits
• Restate on GitHub and the 1.5 release notes
• DBOS Transact for Python and the library overview