DBOS vs Temporal for AI agents (2026)

DBOS and Temporal are both durable execution engines for AI agents: a run picks up where it left off after a crash, and it can make a human-in-the-loop wait for approval. The difference is what’s new in your stack. With DBOS, nothing is: it’s a library, and it checkpoints each workflow and step into a Postgres database you already have. With Temporal, a server holds the state and your workers pull work from it.

So pick DBOS when your app already runs on Postgres and you’d rather not run another system. Pick Temporal when you want the state outside your database, or the choice of pinned or auto-upgrading versions. And if you’d rather run neither, Cadenya is a hosted agent loop with durable execution and approvals built in, and a coding agent can set it up with no account, in a temporary workspace you claim later. What it offers is at the end.

Every price and limit below comes from each vendor’s own pages, checked on September 28, 2026.

DBOS and Temporal side by side

	DBOS	Temporal	Cadenya
What you run yourself	Your app and Postgres. DBOS Transact is a library	Four services (Frontend, History, Matching, Worker) and a database	Nothing. Your app calls an API, and the loop runs on Cadenya
Where the state lives	Your Postgres (“entirely built on Postgres”)	The Temporal server’s database	On Cadenya, which runs the loop
Managed option	Conductor, optional and off your execution path: Pro $99 a month, Teams $499	Temporal Cloud from $0 a month, Business from $500	Hosted: free for 1,000 loops a month, $49 a month for 50,000
What you pay for	Checkpoints: 1 million a month on Pro, then $50 per million	Actions: $50 per million for the first 5 million	Loops: one per LLM request, then $0.0015 a loop
The waiting primitive	send() and recv(), or setEvent() and getEvent()	Signals, Updates, and durable timers	Tool approval: the objective pauses on toolApprovalRequested
Code that changes while runs wait	Runs are tagged with a hash of your code and only recover on that version	Worker Versioning (pinned or auto-upgrade) and patching	Each objective keeps its variation’s configuration snapshot
License	MIT (Conductor is proprietary)	MIT	Apache-2.0 SDKs, and no server to host
SDKs and floors	Python 3.10+, TypeScript on Node 20+, Go 1.25+, Java 17+ (and Kotlin)	Go, Java, Python, TypeScript, .NET, Ruby, PHP	TypeScript on Node 18, Python 3.9, Ruby 3.1, Go 1.22
Throughput	More than 40,000 workflows or steps a second on one Postgres, per DBOS	500 Actions a second on demand on Temporal Cloud, scaling with usage	Hosted, so there are no workers to scale

Self-hosted or managed: what you run

With DBOS you run your app, and durable execution lives in Postgres. “DBOS is entirely built on Postgres”, and any Postgres works: self-hosted, RDS, Aurora, Cloud SQL, Supabase, Neon, and more. Its sizing rule is concrete: 1,000 steps or workflows a second (about 2 billion a month) “requires 4 Postgres vCPUs.” If the database goes away, workflows pause and resume when it’s back.

Conductor is DBOS’s console and recovery service. It’s optional and “entirely out-of-band”, so an outage there doesn’t stop your workflows. Without it, a restarted process recovers its own pending workflows. With several servers, you give each one an executor ID so a crashed server’s work gets picked up.

Temporal is a server: four services and a persistence database (PostgreSQL 13 to 16, MySQL 8.0.19 and later, or Cassandra). Your workers are separate processes that poll it. With Temporal Cloud you rent the server, and you still run the workers.

Human-in-the-loop approvals: how a run waits

DBOS waits on a message, and your approval endpoint sends it:

import { DBOS } from '@dbos-inc/dbos-sdk';

async function refundApprovalFn(refundId: string): Promise<string> {
  // The second argument is the timeout in seconds.
  const approved = await DBOS.recv<boolean>('decision', 7 * 24 * 60 * 60);
  if (approved === null) return 'expired';
  return approved ? `refund ${refundId} sent` : `refund ${refundId} denied`;
}

export const refundApproval = DBOS.registerWorkflow(refundApprovalFn);

// In your approval endpoint:
// await DBOS.send(workflowID, true, 'decision');

recv() returns null when its timeout passes, and DBOS timeouts are durable (“stored in the database and persist across restarts”).

Temporal waits on a condition that a Signal flips:

import { condition, defineSignal, setHandler } from '@temporalio/workflow';

export const decide = defineSignal<[boolean]>('decide');

export async function refundApproval(refundId: string): Promise<string> {
  let approved: boolean | undefined;
  setHandler(decide, (value) => {
    approved = value;
  });

  // Resumes when the decide Signal sets approved.
  await condition(() => approved !== undefined);
  return approved ? `refund ${refundId} sent` : `refund ${refundId} denied`;
}

Versioning: deploying while runs wait

What happens to an agent that’s waiting when you ship new code? Here the two make different bets.

DBOS hashes your source code into an application version and tags every workflow with the version it started on. “When DBOS tries to recover workflows, it only recovers workflows whose version matches the current application version.” So an agent that’s waiting on version A needs an executor on version A to finish after a crash, or you fork it onto new code with ForkWorkflow. Conductor helps you manage those versions.

Temporal gives you a choice with more tooling around it. Pinned workflows finish on their original worker version, which drains while they close. Auto-Upgrade workflows move to new code and stay safe through patching.

Either way, a run that waits means planning for the code you’ll deploy while it waits.

Pricing

DBOS Transact is free under MIT, and your Postgres is the bill. Conductor adds a price: Pro at $99 a month with 1 million checkpoints, then $50 per million, or Teams at $499 with 10 million, then $40 per million. Self-hosting Conductor is an Enterprise option.

Temporal Cloud has no base fee: $50 per million Actions, plus storage, plus support at 10% of usage, with $150 in credits for new accounts. Self-hosted Temporal is free under MIT.

For an agent run with 6 model calls, 3 tool calls, and one approval, both bills stay small at a few thousand runs a month. The Temporal cost breakdown shows the arithmetic for 2,000 and 100,000 runs.

What you still write for an AI agent

Neither is the agent. You write the model loop, tool calls, the stream to your UI, context compaction, and the approval screen. Both help. Pydantic AI supports both as durable execution backends, with pydantic-ai[dbos] for DBOS, and its docs list three more backends for durable execution: Prefect, Restate, and AWS Lambda. DBOS also integrates with LlamaIndex, the OpenAI Agents SDK, Google ADK, and the Vercel AI SDK. Temporal runs the OpenAI Agents SDK as workflows and lists integrations for the AI SDK by Vercel, LangGraph, and Mastra.

Cadenya runs all of those for you.

What does Cadenya offer that DBOS and Temporal don’t?

DBOS and Temporal keep your code alive through crashes, and your code still has to be the agent. Cadenya runs the agent itself, with durable execution and human-in-the-loop approvals built in, no library in your process, and no server to run. Here’s what that covers:

1. Nothing else to run. No DBOS library in your app, no Temporal services, no workers, and no sidecar. The loop runs on Cadenya and your app stays a stateless web tier, so your deploys and restarts never touch a running objective.
2. The agent loop, already written. Cadenya calls the model, runs the tools, streams each reply, and compacts the context window when a conversation gets long. On DBOS or Temporal, that’s the workflow you’d write.
3. No versions to keep alive. An objective keeps its variation’s configuration snapshot even when you edit the variation. There’s no source hash to match on recovery and no worker version to pin or patch.
4. Tools generated from your OpenAPI spec. A tool set turns every operation in an OpenAPI 3 document into a tool, with no OpenAPI-to-MCP generator to run and no hand-written tool list to keep in sync. Cadenya re-checks the document each hour, filters the list, and loads tools on demand. MCP servers and plain HTTP endpoints work too.
5. Human-in-the-loop approvals, screen included. A tool marked for approval pauses the objective on toolApprovalRequested until your backend, a webhook handler that posts to Slack, or a person in the React chat widget approves or denies it. A denial can carry a memo that steers the agent.
6. Any model, on your own keys. The model is a setting on a variation, so switching providers needs no deploy: any model on OpenRouter, or your own endpoint that speaks the OpenAI chat format, billed by your provider. Weighted variations route more traffic to whichever model or prompt users rate higher.
7. Resumable streaming. The event stream honors Last-Event-ID, and the TypeScript SDK reconnects on its own after a drop.
8. Acting on behalf of the signed-in user. A widget session can carry the user’s short-lived token as a secret that overrides the shared API credential, so your API sees that user’s token on each tool call. Pinned parameters fix the IDs the model can’t change.
9. SDKs for the versions you run today. TypeScript on Node 18, Python 3.9, Ruby 3.1, and Go 1.22, all at 1.9.0 and Apache-2.0, plus a CLI and a plain HTTP API. DBOS needs Python 3.10, Node 20, or Go 1.25, and Temporal’s Ruby SDK needs Ruby 3.2 at least.
10. A price in one line. Free for 1,000 loops a month, $49 a month for 50,000, then $0.0015 a loop. A loop is one LLM request, so an agent turn that calls the model 6 times is 6 loops, and there are no seats.

How objectives work walks through an agent turn, and the free plan needs no card.

No account yet? A coding agent can create a temporary workspace with cadenya workspaces create --temporary, run its first objectives there, and hand you a link to claim it, as auth.md explains. To create an account, sign up at app.cadenya.com/signup, then copy your API key from the API keys page at app.cadenya.com/account/apiKeys.