Postgres can execute workflow steps in the same transaction as application data updates, ensuring that both succeed or fail together, which removes the risk of partial updates. When workflow metadata and application data reside in separate databases, each update requires its own transaction and checkpointing, which can lead to inconsistencies if a step commits before its checkpoint is recorded. Co‑locating the workflow state in the same Postgres database allows the workflow engine to write the checkpoint and perform the data change within a single transaction. In this setup, the step runs inside a transaction supplied by the workflow engine, updates the relevant tables, and then records the checkpoint before the transaction commits. If the transaction aborts, both the update and the checkpoint are rolled back, guaranteeing exactly‑once execution. Eliminating the separate checkpoint step means that durable workflows no longer require application‑level bookkeeping to prevent duplicate operations, such as double‑crediting a bank account. For atomic updates across multiple systems, the traditional transactional outbox pattern maintains an auxiliary table; the application writes a message to this table within the same transaction that modifies the primary record. This approach ensures that either both the record change and the message insertion occur, or neither does, providing reliability even when downstream processes fail. DBOS simplifies the outbox pattern by using a user‑defined function that creates a workflow row in the same transaction as the application update, thereby guaranteeing atomicity without maintaining a separate outbox table. Once the transaction commits, a worker can asynchronously dequeue and execute the workflow, delivering the required actions to external systems. DBOS stated that this method reduces operational complexity and improves reliability for scalable, durable execution. The company invites developers to explore the quickstart guide and GitHub repository for implementation details.