DBOS argues that workflow systems should live within the same Postgres database as application data, a departure from typical separation. This co-location enables updates to both workflow metadata and application data within a single database transaction. This strategy aims to eliminate partial failures and simplify the handling of complex edge cases, a significant challenge in distributed systems development.

The primary technical benefit of this approach is enhanced idempotency. By committing workflow step checkpoints and database updates atomically, systems avoid the need for application-level bookkeeping to prevent duplicate operations. For instance, crediting a bank account can be performed exactly once. This transactional guarantee simplifies building fault-tolerant workflows that resume correctly after interruptions.

Furthermore, co-location simplifies achieving atomicity for operations spanning multiple systems, like updating a database record and initiating a fulfillment workflow. Instead of relying on external transactional outbox patterns, a Postgres user-defined function can enqueue a workflow within the application's database transaction. This ensures that database modifications and subsequent workflow initiation are either fully completed or entirely rolled back, preventing inconsistencies.