PostgreSQL as a Workflow Orchestrator: A DBOS Approach

During QCon San Francisco 2025, Jeremy Edberg and qian Li from DBOS presented a non-conventional architectural approach to workflow orchestration: treating PostgreSQL not just as a data store, but as the orchestration layer itself. Their talk addressed a persistent problem in distributed systems: workflows frequently fail, recovery mechanisms are complex, and visibility into workflow state remains challenging.

According to the speakers, modern applications routinely write workflows, but current solutions struggle with basic challenges. Failures occur frequently, existing orchestration tools lack adequate visibility into what’s happening, and coordination logic becomes scattered across multiple systems. “Your database is all you need,” Li noted, pointing to the reality that most teams already have most of the infrastructure to implement workflow support themselves, given an application-level “workflow wrapper” libary.

The challenges of external orchestration

The DBOS Transact approach, available as an open-source library under an MIT license for Python, TypeScript, Go, and Java, inverts the conventional architecture stack. Rather of building orchestration layers on top of databases, workflows translate directly into database operations.

The Transact approach – an App Server with a library performing distributed orchestration using the database

The library relies on a checkpoint system. Before executing any workflow step, the system records the input to the database, and after each step execution, it checkpoints the output. When interruptions occur, workflows can resume from the last accomplished checkpoint.