DBOS: Durable Execution as a Library, Not a Platform

This is the third in a short series on durable execution. We covered Temporal, where the engine records every step and replays your workflow after a crash. We covered Resonate, where a promise record outlives the processes that create it. Both are systems you adopt, with infrastructure to run and a runtime to understand.

If you want the earlier chapters, we covered Temporal and Resonate already.

DBOS attacks the same problem from the opposite direction. It is a library you install, not a platform you deploy. You annotate ordinary functions, point the library at a Postgres database you already have, and your program becomes resilient to crashes and restarts.

What it actually looks like

In TypeScript, a workflow is a function decorated with @DBOS.workflow(), and every side effect inside it is a step:

class Checkout {
  @DBOS.step()
  static async chargeCard(order: Order) {
    /* ... */
  }

  @DBOS.step()
  static async reserveInventory(order: Order) {
    /* ... */
  }

  @DBOS.workflow()
  static async placeOrder(order: Order) {
    await Checkout.chargeCard(order);
    await Checkout.reserveInventory(order);
  }
}

If the process dies between the two steps, DBOS notices on restart that chargeCard already completed for this workflow and resumes from reserveInventory. Same promise as before, but the execution state lives in a Postgres table rather than in a dedicated workflow server.

The same story exists in Python, Go, and Java, which makes it one of the few durable execution options with real multi language support.

The interesting design choice

DBOS came out of research on whether an operating system kernel could provide fault tolerance, and the design still shows it. Instead of building a database and asking you to route work through it, DBOS uses your database. Workflows, queues, scheduled jobs, and durable sleeps are all rows in your Postgres.

That decision drives most of its character:

• There is no second system to operate. No Temporal server, no separate coordination tier. Your deployment story is your app plus Postgres, which you probably already run.
• Queues are SQL. Enqueueing work is a database write, so ordinary Postgres tooling, backups, and observability apply to your task queue.
• Transactions are exactly once. Because the execution record and your data live in the same database, DBOS can commit app data and workflow progress together, which replay engines handle with more ceremony.
• Durable sleeps cost nothing. A workflow can wait a month, stored as a wakeup time in a row, waking on schedule across restarts.

The cost model claim follows from the architecture: pending work is rows, not compute, so idle time is nearly free.

The trade

The same honesty we applied to Temporal applies here.

First, you are bound to Postgres. Execution state and application state in one database is a strength for consistency and a constraint for scale. If your database is the bottleneck, your workflow engine is now part of that bottleneck. DBOS argues Postgres scales further than people think, and they are usually right, but it is a coupling either way.

Second, the determinism rule from Temporal exists here too. Workflows must be deterministic, and randomness, clock reads, and direct API calls belong in steps. The library enforces less than an engine does, so discipline is on you.

Third, the ecosystem is younger. Fewer connectors, fewer examples, smaller community. When something breaks, you are reading source code rather than searching a large knowledge base.

Picking among the three

After three posts, the decision tree is fairly simple:

1. DBOS if you already run Postgres, want durability with the least new infrastructure, and prefer your codebase to stay a normal codebase.
2. Resonate if your problem is coordination across languages, runtimes, and time, and you want the contract, not the code, to be the durable thing.
3. Temporal if you have a large organization running many long business processes and want a mature platform that owns the whole story, execution history, and operations.

All three sell the same outcome, functions that survive failure, and all three charge a different price for it. DBOS charges the least infrastructure and the most trust in your own database.

That trade is often the right one. The best reliability system is the one small teams actually deploy, and a library with a decorator has a much shorter path from reading the docs to running in production than a platform with a cluster.

If you want to try it in your own codebase, the official site is at dbos.dev, and the documentation lives at docs.dbos.dev.