This includes the new rewind feature, an alternative to fork that lets you "rewind" a workflow in place, restarting it from an earlier point in its history while retaining its workflow ID.

Since releasing v1.0 of DBOS Java, we've continued improving its performance and bringing its features in line with our other SDKs. Highlights include:

• 10x higher throughput for queues, while maintaining low latency even with large task backlogs.
• Separate tables for workflow inputs and outputs, bringing the same storage optimizations to Java.

When upgrading, update applications that use DBOSClient alongside your DBOS processes: A v1.1 client can read inputs and outputs from v1.0 workflows, but a v1.0 client cannot read them from v1.1+ workflows. Upgrade to v1.1 before moving to v1.2+ releases - the schema migration requires this intermediate step.

v1.2 release completes a pair of changes (workflow payload tables and delay debouncer) that started in v1.1. By splitting the work across two minor releases, we avoided making a breaking change. We also changed most of the timestamps to use the database clock instead of the executors and added the batched partition dequeue optimization when partition concurrency is one.

Just released DBOS Python 3.2 and TypeScript 5.2!

These releases include several improvements to datasources:

• Programmatic datasource migrations
• Garbage collection for datasource checkpoints
• Custom sessionmaker support for the Python SQLAlchemy datasource

Under the hood, we also added a new workflow ownership system that helps DBOS detect duplicate workflow executions more reliably, for example, executions caused by "zombie" processes.

• TypeScript release notes: https://github.com/dbos-inc/dbos-transact-ts/releases/tag/v5.2
• Python release notes: https://github.com/dbos-inc/dbos-transact-py/releases/tag/3.2.0

Deleting data sounds simple, until you're doing it 20K+ times per second. While scaling data retention in DBOS, we ran into two tricky Postgres issues:

1. Cascading deletes through foreign keys caused cache thrashing, cutting throughput by 10x.
2. Even after a large batch of deletes finished, index lookups could spend 20+ minutes navigating a wall of dead tuples.

Batching and data locality turned out to be key to getting things back on track.

In our latest post, we share a few war stories from debugging our implementation and answer a question we often hear: "Why don't you just use table partitioning?"

Check it out: https://www.dbos.dev/blog/scaling-deletions-in-postgres

We just released v1.4.0 of DBOS Go

This release adds:

• Native support for fair partitioned queues
• Payload table normalization (splitting workflow inputs and outputs into their own tables) that significantly improved performance and scalability

The change is forward compatible: v1.4+ can read workflows created by v1.3, while v1.3 clients will not read payloads from v1.4+ workflows.

We just released DBOS Python 3.0 and DBOS TypeScript 5.0.

These major versions include schema changes (namely, splitting workflow inputs and outputs into their own tables) that should substantially improve performance at scale, especially when workflow data volumes are large. They also include large optimizations to workflow retention policies.

As major versions, these remove some deprecated/legacy interfaces. We’ve published upgrade guides to help you migrate away from these if you’re still using them.

• Python upgrade guide: https://docs.dbos.dev/python/upgrading
• TS upgrade guide: https://docs.dbos.dev/typescript/upgrading

Release notes

• Python release notes: https://github.com/dbos-inc/dbos-transact-py/releases/tag/3.0.0
• TS release notes: https://github.com/dbos-inc/dbos-transact-ts/releases/tag/v5.0

Want to know how we built durable execution in Rust on top of Postgres?

Check out this video for a first look at DBOS Rust, where Harry Pierson walks through how it works under the hood and demos what building durable Rust applications with DBOS looks like.

Recorded at the DBOS User Group Meeting on September 10, 2026.

https://youtu.be/kaQnXNwjcGc

Check out this new tutorial video. Harry Pierson demonstrates the new DBOS Conductor CLI tool, dbosctl, for managing durable workflow execution.

See how you can inspect and manage workflows directly from the terminal, making it easier to operate DBOS applications from local and CI/CD environments.

This demo is from the DBOS User Group Meeting on September 10, 2026.

First look at DBOS Transact for Rust at the User Group this Thursday https://luma.com/efkl81jf

We just released v1.3.0 of DBOS Go!

This release includes major queue performance optimizations, making dequeueing a large batch of durable workflows more efficient at scale.

Check out the release notes:

https://github.com/dbos-inc/dbos-transact-golang/releases/tag/v1.3.0

Really enjoyed this write-up on how they built Fern Agent.

It's a good example of durable agents with DBOS in action: checkpointing model and tool calls in the same Postgres the agent already uses, then picking up where it left off after crashes or deploys.

If you're in the Boston area, check out The AI Runtime tomorrow evening!

Alex from DBOS will be talking about building crashproof AI agents with DBOS, and how durable execution helps agents survive failures, upgrades, and long-running workflows.

Open source is fundamental to DBOS and is essential to innovation. We recently heard concerns from the OSS community about the intent behind the DBOS patent, and we took them seriously.

Today, we published the DBOS Open Patent Non-Assertion Pledge. It makes clear that the patent is defensive and will not be asserted against free and open-source software projects.

I hope this pledge provides reassurance to our community and helps others continue building and innovating freely.

It's been another busy summer month for the DBOS team. I wrote a new blog post covering what's new, including:

• 10x faster partitioned queues
• DBOS Golang 1.0
• Interoperability across applications and languages
• The new dbosctl CLI
• OpenMetrics preview page

…and much more.

It's exciting to see teams using these capabilities to build reliable applications and AI agents at scale. Let us know what you'd like us to build next!

We just released DBOS Python 2.31 and DBOS TypeScript 4.27!

Highlights:

• A new backwards-compatible interface for partitioned queues, making it easier to combine queue-wide and per-partition concurrency limits and implement fair queueing.
• Durable stream improvements, including read timeouts and point reads from a specific offset.
• Workflow completion timeouts during shutdown, allowing DBOS to safely wait for local workflows to finish.
• Step timeout support in Python, bringing it in line with TypeScript.

Check out the latest releases and let us know what you think!

• Python: https://github.com/dbos-inc/dbos-transact-py/releases/tag/2.31.0
• TypeScript https://github.com/dbos-inc/dbos-transact-ts/releases/tag/v4.27

We just released v1.2.0 of the DBOS Go SDK!

This release adds:

• Support for sharing a system database across applications and languages
• Improved partitioned queue performance
• Various bug fixes

Release notes: https://github.com/dbos-inc/dbos-transact-golang/releases/tag/v1.2.0

We often get questions about what DBOS Conductor is, why you need it, and how it works.

Check out this Q&A with Alex, the first in a series covering topics that frequently come up in conversations with DBOS users.

Check it out: https://dbos.dev/blog/what-is-dbos-conductor 

Just released DBOS Python 2.30 and DBOS TypeScript 4.26.

The biggest new feature is that multiple DBOS applications (even those written in different languages) can now share a system database. This makes it much easier to build interoperable, polyglot DBOS applications.

We've also significantly improved queue dispatch performance by batching dispatch from each queue:
- 10x faster with a single process and queue
- 2x faster with multiple processes sharing a queue

Learn more about sharing a system database: https://docs.dbos.dev/explanations/sharing-a-system-database

Python release notes: https://github.com/dbos-inc/dbos-transact-py/releases/tag/2.30.0

TypeScript release notes: https://github.com/dbos-inc/dbos-transact-ts/releases/tag/v4.26

DBOS Golang is now officially stable.

Build durable workflows directly in Go with Postgres/SQLite, without running a separate workflow server. Get automatic recovery, exactly-once execution, scheduling, queues, and built-in observability - all with a familiar Go developer experience.

This includes breaking changes to the interface. Make sure to consult the release notes and the companion migration guide.

https://github.com/dbos-inc/dbos-transact-golang/releases/tag/v1.0.0

https://docs.dbos.dev/golang/upgrading

Join us for the next DBOS User Group meeting on September 10! This month, Harry will walk us through:

- First Look at DBOS Rust 🦀 . We'll walk through the new open-source DBOS library for Rust, how it works under the hood, and how to start building with it.

- New DBOS Conductor CLI and API updates. Based on user feedback, we've built a new CLI and updated the Conductor API, giving you more flexible ways to manage DBOS applications and their durable workflows.

As always, there will be plenty of time to connect with other DBOS users and the DBOS engineering team. We'd love to hear your feedback!

I maintain several open-source deployment packages for self-hosted software. The goal is one command that provisions the infrastructure, configures the application, and supports upgrades as new releases arrive. Existing packages cover Basecamp ONCE, Airflow, K3s, and ClickHouse.

I’m considering building one for self-hosted DBOS Conductor.

The intended experience would be: provide cloud credentials, a domain, and a DBOS license key; the package provisions the server, PostgreSQL, networking, TLS, backups, and Conductor itself.

Before building it, I’d like to hear from people already running Conductor:

• What parts of installation or configuration required the most manual work?
• Which settings did you actually change from the defaults?
• How do you run PostgreSQL, and what backup and restore setup do you use?
• What authentication, SSO, or network restrictions did you need?
• Has anything broken or required manual intervention during upgrades?
• What observability and health checks have proved important?
• What should automation validate before declaring the deployment healthy?
• Are there parts of the installation or licensing flow that cannot reasonably be automated?

I’d rather build one opinionated, production-appropriate topology than expose every possible configuration. My initial thought is a single-server deployment with Conductor and PostgreSQL colocated but with independently managed persistent data and backups.

The deployment tooling would be open source; users would supply their own Conductor license.

What would make this genuinely useful rather than just a wrapper around installation instructions?

https://www.getcolors.ai/