DBOS Transact: Reimagining Workflow Orchestration with PostgreSQL
Table of Contents
A new approach treats the database not as a data store, but as the central engine for managing and executing complex workflows, promising increased reliability and simplified operations.
Modern applications are increasingly reliant on workflows, but existing orchestration tools often struggle with inherent challenges like frequent failures, limited visibility, and fragmented coordination logic. A novel solution presented at QCon San Francisco 2025 by Jeremy Edberg and Qian Li from DBOS proposes a radical shift: leveraging PostgreSQL itself as the workflow orchestration layer.
“Your database is all you need,” Li stated, highlighting the potential for teams to build robust workflow support using infrastructure they already possess, coupled with a lightweight application-level “workflow wrapper” library. This approach directly addresses the persistent problems plaguing distributed systems – the complexity of recovery and the difficulty of understanding workflow state.
Inverting the Architecture Stack with DBOS Transact
The DBOS Transact approach, available as an open-source library under an MIT license for Python, TypeScript, Go, and Java, fundamentally inverts the traditional architecture. Instead of layering orchestration tools on top of databases, Transact translates workflows directly into database operations. This is achieved through a checkpoint system: before each step in a workflow is executed, the input is recorded in the database, and the output is checkpointed after completion.
This system allows workflows to seamlessly resume from the last successful checkpoint in the event of an interruption, eliminating the need to restart from scratch. Crucially, this leverages PostgreSQL’s inherent ACID (Atomicity, Consistency, Isolation, Durability) properties to guarantee exactly-once execution semantics without requiring additional orchestration infrastructure.
Practical Capabilities: SQL-Powered Workflow Management
The database-backed approach unlocks several practical benefits for operational teams. Workflow management becomes accessible through standard SQL queries, enabling teams to easily list, search, cancel, and resume workflows directly within the database. The DBOS team also demonstrated a powerful “fork” capability for debugging production issues. This allows developers to restart a workflow from a specific step by duplicating the original inputs and outputs, then re-executing with updated code – significantly simplifying bug fixes and event replay.
Addressing the Challenges of a Database-Centric Approach
The presenters acknowledged inherent challenges. Lock contention, arising when multiple workers attempt to process tasks from the same queue, could potentially degrade performance. The team mitigates this through PostgreSQL’s “FOR UPDATE SKIP LOCKED” clause, allowing each worker to select and lock only available workflow rows, enabling efficient concurrent processing.
Decentralized cron scheduling also presented a hurdle. Rather than relying on a central scheduler, each worker independently runs a cron scheduler, using the scheduled time as a unique workflow identifier to ensure idempotent execution. To avoid “thundering herd” problems – where multiple workers wake up simultaneously – the library introduces random jitter to sleep intervals, distributing the load and verifying workflow existence before execution.
Testing workflows is also streamlined in this model. Workflows function identically in both local development and production environments, and the checkpoint mechanism simplifies unit testing through easier mocking and state management.
A Historical Parallel: Lessons from Windows Workflow Foundation
This architectural pattern isn’t entirely new. Nearly two decades ago, Microsoft’s Windows Workflow Foundation utilized SQL Server persistence to maintain workflow state. However, that earlier approach relied on domain-specific language (DSL)-based workflow definitions and substantial configuration, limiting its adoption primarily to Microsoft’s own products. The DBOS approach distinguishes itself by employing lightweight code annotations within mainstream programming languages, avoiding the complexity of a separate workflow definition language.
