October has been another exciting month for DBOS. We introduced new tools for managing workflows, improved reliability for distributed execution, and added support for horizontally scaling Postgres-backed durable workflows to over 1 million workflows per second.
Here's a summary of what's new:
New in DBOS Transact open source libraries
- Rewind workflows to any step
- Improved workflow ownership and conflict resolution
Introducing the DBOS Transact Enterprise Extension
- A commercial extension to DBOS Transact with advanced features available on all paid plans
- Automatic workflow version upgrades
- Horizontal scaling with sharded Postgres
Read on for the details.
New Features in DBOS Transact Open Source
Rewinding Workflows to Any Step
You can now rewind a workflow to a specific step and re-execute it, without changing its workflow ID.
When you rewind a workflow, DBOS discards its checkpoints from the selected step onward, then re-enqueues it for execution. Earlier steps replay their recorded results without re-executing, while the rewound steps run again.
This is especially useful when a workflow's ID is referenced by other parts of your application, such as an order ID or an idempotency key. Other workflows and clients can continue interacting with the same workflow through its events, messages, and streams.
Rewinding also makes it easier to recover from application bugs. For example, if a workflow fails because of a bug in one step, you can deploy a fix and rewind the workflow to that step on the new application version, without losing its identity or repeating previously completed work.
Available today in TypeScript, Python, and Go. Java and Rust support are coming soon.
Improved Workflow Ownership and Conflict Resolution
We improved how DBOS handles concurrent workflow executions, preventing "zombie" executors from interfering with workflows that have been recovered or resumed elsewhere.
In a distributed system, an executor may temporarily lose connectivity and be considered dead, causing another executor to recover its workflows. If the original executor is still running, both could attempt to execute the same workflow.
To prevent conflicting updates, DBOS now uses workflow ownership tokens. Each execution receives a unique token when it starts running a workflow. Before writing a checkpoint, it verifies that it still owns the workflow, using the same database transaction as the checkpoint write.
If another execution has taken ownership, the old executor can no longer write checkpoints. Instead, it stops at its next checkpoint and waits for the owning execution's recorded result. The same mechanism also guarantees cancelled workflows stop at their next checkpoint.
This makes workflow recovery and cancellation more reliable in distributed deployments, particularly during rolling deployments, network interruptions, and executor failures. It prevents stale executions from overwriting workflow state and ensures that only the current owner can commit workflow progress.
Read more about workflow ownership in the docs.
Introducing the DBOS Transact Enterprise Extension
With our latest releases in DBOS Transact libraries, we've introduced the DBOS Transact Enterprise extension.
The biggest change is that we moved the DBOS Conductor client into a separate Enterprise package. This keeps our open-source libraries lightweight, removing unnecessary dependencies such as WebSockets for applications that don't use Conductor.
The new extension helps teams operate DBOS at scale, with advanced capabilities such as automatic workflow version upgrades and horizontal scaling with sharded Postgres. These features are available to users on all paid plans.
If you're only using the open-source DBOS libraries, nothing changes: you can upgrade and use DBOS as usual.
If your application uses DBOS Conductor, please install this package when upgrading to the latest version of DBOS. Depending on your language, follow one of the steps below:
- Python v3.3+:
pip install "dbos[enterprise]" - TypeScript v5.3+:
npm install @dbos-inc/dbos-enterprise -
Go v1.7+: Run
go get go.dbos.dev/dbos-enterprise-go, then addimport _ "go.dbos.dev/dbos-enterprise-go"to your application.
The DBOS Enterprise Extension for Java and Rust are coming soon.
Automatic Workflow Version Upgrades
Deploying new application versions can be tricky when you have long-running workflows. Some workflows may still be running or queued on an older version, requiring you to keep old workers running until they finish.
With the DBOS Transact Enterprise extension activated, you can now automatically migrate workflows from older application versions to the latest version, making deployments much easier.
Here's how it works:
- Queued and delayed workflows are automatically reassigned to the latest application version.
- Running workflows receive a configurable grace period to finish. If they don't finish in time, they're re-enqueued for recovery on the new version.
Under the hood, DBOS coordinates upgrades across workers using Postgres advisory locks to prevent conflicts. Workflows are processed in batches to minimize database contention.
This is especially useful for applications with long-running workflows, background jobs, or AI agents that may execute for hours or days. Instead of manually migrating workflows or maintaining old application versions indefinitely, you can roll out new versions and let DBOS handle the transition.
Available today in TypeScript, Python, and Go. Java and Rust support are coming soon.
Horizontal Scaling with Sharded Postgres
We previously demonstrated that a single Postgres database can handle tens of thousands of workflows per second. But what happens when you need hundreds of thousands, or even millions?
This month, we added support for sharded Postgres and demonstrated linear scaling to over 1 million workflows per second in our benchmarks.
DBOS's architecture makes this possible with a relatively simple design: all the state needed to execute a workflow
can live on a single shard. We added a shard_key column to the workflow status table and its dependent
tables, so each workflow's metadata, step checkpoints, and other state are stored together on one shard. This allows
most workflow operations, including checkpointing steps, enqueueing workflows, and sending messages, to execute
entirely within one shard.
The result is that adding more Postgres shards lets DBOS scale workflow throughput horizontally, without introducing a separate orchestration system.
This is particularly useful for high-throughput workloads such as AI agents, event processing, and large-scale background job systems. You can continue using the familiar DBOS programming model while scaling your database infrastructure as your workload grows.
Read more about sharding in our latest blog post.
Learn More about Durable Workflow Orchestration
If you like making systems reliable, we'd love to hear from you. At DBOS, our goal is to make durable workflows as easy to work with as possible. Check it out:
- Quickstart: https://docs.dbos.dev/quickstart
- GitHub: https://github.com/dbos-inc
- Discord community: https://discord.gg/eMUHrvbu67
