October 2026 Summaries

DBOS’s October updates introduce workflow-management and scaling enhancements for its Transact platform, including the ability to rewind workflows to a chosen step while retaining their IDs and replaying earlier recorded results. Distributed execution reliability was strengthened through ownership tokens that prevent stale or “zombie” executors from writing conflicting checkpoints after recovery, cancellation, or connectivity failures. The company also launched the DBOS Transact Enterprise extension, which separates the Conductor client from the open-source libraries and adds paid-plan features such as automatic workflow version upgrades and sharded Postgres support. Version upgrades can move queued workflows to new application releases and recover long-running workflows on the latest version after a configurable grace period, while Postgres sharding stores each workflow’s state on one shard to enable horizontal scaling. DBOS reports benchmarked linear scaling beyond one million workflows per second, targeting demanding uses such as AI agents, event processing, and large-scale background jobs.

A Postgres-backed durable workflow system was scaled from roughly 20,000 to more than 1 million workflows per second by sharding workload data across 50 RDS Postgres servers, with PgDog routing requests according to uniformly distributed shard keys. The benchmark used simple no-op workflows, 48 worker processes per shard, and a design in which all data and operations for an individual workflow remained on one shard, avoiding costly cross-shard coordination. Initial testing revealed that throughput became unstable beyond approximately 8–16 shards because temporary slowdowns on one shard triggered a feedback loop: longer dequeue queries led more workers to target that shard, increasing lock contention and further delaying queries. The system addressed this metastability by using PostgreSQL advisory locks to limit concurrent dequeue activity on each shard, causing workers unable to obtain a dequeue lock to move to another shard rather than wait. This approach prevented individual shards from becoming overloaded and enabled stable near-linear scaling for high-volume durable workflow execution.

Database application architecture has evolved from early two-tier client-DBMS systems to three-tier models that separated presentation, business logic, and database functions to improve scalability, connection management, and resource use. The passage argues that modern data-intensive applications, particularly agentic AI systems, multi-step business processes, and high-volume consumer platforms, increasingly require workflow orchestrators rather than conventional application servers because they must manage long-running graph-based tasks, preserve durable state, recover from failures, coordinate step execution, scale elastically, and undo or compensate for completed actions when later steps fail. Workflow orchestration can reduce application complexity by externalizing control flow and error handling, while providing visual monitoring, debugging, checkpoint-based recovery, and support for compensating transactions. It further presents DBOS’s approach of embedding workflow orchestration in the database already used by an application, asserting that this can avoid separate orchestration infrastructure and additional messaging while enabling durable workflow execution.