Durable AI agents without Temporal: exactly-once workflows on Postgres with DBOS (2026)

Summary. An AI agent that loses its place when the process crashes is a support ticket waiting to happen. DBOS solves that by checkpointing every workflow step to Postgres, so a crashed agent replays its completed steps and resumes exactly where it left off, with no separate orchestrator server to run. The open-source DBOS Transact library adds $0 in licence cost and supports 4 languages (TypeScript, Python, Java, and Go). On July 20, 2026 DBOS shipped three releases that matter for agent teams: DBOSify, a drop-in replacement for Temporal Python that runs entirely on Postgres; an @dbos-inc/vercel-ai package that makes Vercel AI SDK agents durable; and transactional datasources for exactly-once semantics. That same July release lifted durable-stream throughput up to 20x. The architecture argument behind all of it is one Peter Kraft, writing on the DBOS engineering blog, made in a May 20, 2026 post: external orchestration, the model behind Temporal, Airflow, and AWS Step Functions, is "fundamentally overcomplicated." This guide explains how DBOS works, what shipped, the code to make an agent durable, and where Temporal still wins.

Durable execution is not a new idea, but 2026 made it urgent. Agent frameworks now run long, multi-step loops that call tools, wait on APIs, and spend real money per step. When one of those processes dies halfway through, you do not want it to start over, double-charge a customer, or drop the thread. You want it to pick up from the last completed step.

What durable execution is, and why agents need it

A durable workflow checkpoints its progress to a database as it runs. If the program crashes, it reloads from the last checkpoint and continues from the last completed step. DBOS uses the video-game metaphor for it: you regularly "save" your program's progress so that if it crashes, you can "reload" it (DBOS).

For an AI agent, the steps are the expensive, side-effecting actions: a model call, a tool invocation, a database write, a payment. Without durability, a crash after step 3 of 6 re-runs steps 1 through 3, repeating their side effects. With durability, the completed steps are read back from their checkpoints and only step 4 onward runs. That is the difference between an agent that is safe to run unattended and one that is not.

How DBOS works: Postgres is the orchestrator

Most durable-workflow systems use external orchestration. A central server (Temporal, Airflow, AWS Step Functions) holds the workflow state, dispatches each step to a worker, receives the result, checkpoints it, and dispatches the next step. DBOS argues that if durability is really about writing checkpoints to a database, the separate orchestrator is redundant (DBOS).

In the DBOS model, application servers talk to Postgres directly. A client submits a workflow by inserting a row into a Postgres workflows table. Application servers poll that table, dequeue work, and execute it, checkpointing the output of each step back to Postgres. If a server crashes mid-workflow, another server recovers the workflow from its checkpoints and continues. Workers cooperatively dequeue using row-locking clauses so each workflow is picked up by exactly one worker, and Postgres integrity constraints catch any duplicate work at checkpoint time.

Three properties fall out of that design. Scale is Postgres scale: a single Postgres server can drive tens of thousands of workflows per second, and you can go further with sharded or distributed Postgres. Observability is built in, because every workflow and step is a row you can query in SQL. And the only new point of failure is Postgres itself, which you already run, back up, and secure. As DBOS puts it, if Postgres is healthy, your workflows are healthy.

Because the checkpoints live in ordinary tables, you monitor agents with SQL you already know. A query to find recently failed workflows looks like this (exact table and column names are in the DBOS docs and can shift between versions):

            select workflow_uuid, name, status, created_at
from dbos.workflow_status
where status = 'ERROR'
  and created_at > now() - interval '1 day'
order by created_at desc;
          

What shipped in July 2026

The July 20, 2026 release notes are why this is worth writing about now. Three items target agent builders directly (DBOS).

The Vercel AI SDK integration is the headline for most agent teams. It is implemented as standard AI SDK middleware, so existing providers, models, and calls like generateText, streamText, and ToolLoopAgent keep working unchanged.

Make a Vercel AI SDK agent durable

The pattern DBOS documents is to wrap your model with durableCalls and run generation inside a DBOS workflow. Every action the agent takes is then checkpointed in Postgres, and if the process crashes mid-run, DBOS replays the completed steps and the agent resumes exactly where it left off. The shape looks like this:

            import { DBOS } from "@dbos-inc/dbos-sdk";
import { durableCalls } from "@dbos-inc/vercel-ai";
import { generateText } from "ai";
import { openai } from "@ai-sdk/openai";

// Wrap the model once; each call becomes a checkpointed step.
const model = durableCalls(openai("gpt-4.1"));

class SupportAgent {
  @DBOS.workflow()
  static async resolve(ticketId: string) {
    const { text } = await generateText({
      model,
      prompt: `Resolve ticket ${ticketId}`,
      // tool calls inside the loop are checkpointed too
    });
    return text;
  }
}
          

If a worker dies after the model call but before the workflow returns, DBOS does not re-issue the model call on restart; it reads the checkpointed result and continues. That is the behaviour you want when each model call costs money and each tool call has a side effect.

Move a Python agent off Temporal with DBOSify

If you already wrote agents against Temporal Python, DBOSify is the lowest-effort path off the Temporal server. It runs your durable workflows, activities, signals, updates, retries, and recovery on Postgres instead. The change is the import and the connection target:

            # Before:
# import temporalio

# After: same workflow and activity code, no Temporal server
import dbosify

# Connect your workers and clients to a Postgres database
# instead of a Temporal frontend. Everything else stays the same.
          

DBOSify keeps the Temporal programming model you know while removing the cluster you had to operate. For teams that adopted Temporal for durability but never wanted to run its multi-service backend, that is the whole pitch.

Getting started in a few lines

Adoption is deliberately small. Install the library, point it at a Postgres connection string, and annotate the functions you want to be durable. In Python it looks like this:

            pip install dbos
          

            from dbos import DBOS, DBOSConfig

DBOS(config=DBOSConfig(name="agent", database_url=os.environ["DBOS_DATABASE_URL"]))

@DBOS.workflow()
def run_agent(task: str):
    plan = plan_step(task)     # each step is checkpointed to Postgres
    return act_step(plan)

DBOS.launch()
          

There is no server to stand up and no schema to hand-design; DBOS creates the tables it needs in your database on launch. TypeScript, Java, and Go follow the same shape with language-native syntax. Because durability is a few annotations rather than a rearchitecture, most teams can add it to an existing backend in a day, and remove it just as easily if they change their mind.

DBOS vs Temporal: the honest comparison

Temporal is a mature, battle-tested system, and it is the right answer for some teams. The difference is architectural, and it drives everything else (DBOS vs Temporal; why DBOS).

The short version: DBOS is faster to adopt, cheaper to run, and simpler to operate when you already have Postgres, because it reuses infrastructure you already secure and back up. Temporal earns its keep when you cannot or do not want to put Postgres in the critical path, or when you need a language DBOS does not yet support. A fuller external take on the trade-off is in this independent DBOS vs Temporal analysis and this durable workflow engines comparison.

The failure modes durability removes

Durable execution is not about happy-path throughput; it is about what happens when things break. For agents, three failure modes are the usual culprits. A process restart mid-loop that re-runs paid model calls and duplicated tool side effects. A slow external API that hangs one step and stalls the whole workflow. And a partial database write that leaves state inconsistent when the agent dies between the write and the checkpoint.

DBOS addresses each with a Postgres-native mechanism. Completed steps are read from checkpoints on recovery, so they do not re-run. Cooperative step timeouts, added in the July 2026 release, cap how long any single step can block. And transactional datasources let a step's application-database write and its durability checkpoint commit in the same transaction, which is where the exactly-once guarantee comes from. This is the reliability layer that sits underneath the concerns we cover in AI agent evals and CI/CD for silent failures and the governance layers for enterprise AI agents: evals catch bad outputs, durability keeps a crash from corrupting state in the first place.

Where the agent's state should live

Durable execution puts your agent's execution history in Postgres, which raises a natural design question: should the agent's working state and memory live there too? For many teams the answer is yes, because one database for both execution checkpoints and agent state is simpler to reason about and to secure. We work through that decision in Lakebase vs self-managed Postgres for AI agent state, and the broader build in our guide to production-grade enterprise AI agents. If your agents run on Kubernetes, the sandboxing and state patterns in stateful AI agents on Kubernetes pair well with a Postgres-backed durability layer.

DBOS is already used this way in production. Its published customer stories include Bristol Myers Squibb, the agent startup Yutori for large-scale durable agentic AI, and Dosu.

India-specific considerations

For teams building in India, the Postgres-backed model has a practical compliance benefit. An external orchestrator sees and stores your workflow and step data, which for an agent handling personal data means that data transits another system you must secure and account for. With DBOS, workflow data stays in your Postgres and never leaves it, so if your database already sits in an Indian region, your durable-execution state does too. Under the Digital Personal Data Protection Act 2023, keeping agent state and execution history inside a database you control makes data-residency and access questions easier to answer. A managed Postgres instance suitable for this starts in the low thousands of rupees per month, well under the cost and operational load of running a separate orchestration cluster. eCorpIT designs deployments aligned with DPDP Act requirements; we do not claim a certification we do not hold.

When to reach for DBOS

Reach for DBOS when you already run Postgres and want durable agents without standing up new infrastructure, when you want to move off a Temporal cluster you never wanted to operate, or when you want your agent's execution history queryable in plain SQL. Reach for a dedicated orchestrator when Postgres cannot be in the critical path or you need a language DBOS does not support. For most agent teams shipping in 2026, the smaller, Postgres-native option is the one that gets durability into production fastest.

FAQ

How eCorpIT can help

eCorpIT builds reliable AI agents and backends, and durability is where reliability usually breaks first. We add Postgres-backed durable execution to agent workflows so a crash never re-runs a paid model call or corrupts state, wire up the observability and step timeouts that keep long loops healthy, and help teams move off an orchestration cluster they never wanted to operate. For Indian deployments we design agent state and execution history to sit in a Postgres instance you control, aligned with DPDP Act 2023 requirements. To scope a durable-agent build or a Temporal migration, contact our engineering team.

References

1. Postgres is all you need for durable workflows, DBOS (Peter Kraft)

1. What's new in DBOS, July 2026, DBOS (Qian Li)

1. DBOS vs. Temporal, compare durable workflow alternatives, DBOS

1. Why DBOS?, DBOS Docs

1. DBOS Transact, open source durable execution library, DBOS

1. DBOS pricing, DBOS

1. dbos-transact-py, database-backed durable Python workflows, GitHub

1. Running durable workflows in Postgres using DBOS, Supabase

1. Build reliable AI agents with durable execution, Pydantic AI + DBOS

1. DBOS vs Temporal: choosing durable execution in 2026, Tiago Balbi

1. Durable workflow engines comparison: Temporal, DBOS Transact, Prefect, custom, Dev.to (Mahdi Shamlou)

_Last updated: August 2, 2026._