Postgres-backed Durable Workflow Execution | DBOS

DBOS Video: 4 Billion Workflows Per Day

Products

DBOS TransactOpen source durable execution library

DBOS ConductorControl plane for agents & workflowsPricingCustomersResources

About DBOSMeet the team simplifying reliability.

VideosDemos, deep dives, and more DBOS.

PartnersExplore the DBOS ecosystem.Docs

QuickstartLaunch your first workflow in minutes.

DocsStep-by-step guides & real-world use cases.

Example ApplicationsReady-to-run code to spark your project.Blog

Explore

...

dbos/dbos-transact-tsDurable Execution Library - TypeScriptdbos/dbos-transact-pyDurable Execution Library - Pythondbos-inc/dbos-transact-goDurable Execution Library - Godbos-inc/dbos-transact-javaDurable Execution Library - Javadbos-inc/dbos-demo-appsDemo DBOS applicationsSee all repos

Sign in

Get started

July 24: DBOS User Group Meeting

Products

DBOS TransactOpen source durable execution library

DBOS CloudDeploy with a click, scale to millionsCustomersPricingBlogDocsResourcesAbout DBOSSee our story, meet our team.VideosDBOS concepts and best practicesStart your projectLogin

LoginStart your project

Back to insightsPostgres is All You Need for Durable WorkflowsPeter KraftMay 20, 2026DBOS ArchitectureDurable workflows are a simple but powerful tool for building reliable programs. The idea is that as your program runs, you regularly checkpoint its progress to a database. That way, if your program ever crashes or fails, you can reload from the last checkpoint to recover it from its last completed step. You can think of this like saving in a video game: you regularly “save” your program’s progress so that if it crashes, you can “reload” it from its last checkpoint.Most commonly, durable workflows are implemented via external orchestration. This is the pattern used by systems like Temporal, Airflow, and AWS Step Functions. In this model, durable programs are written as workflows of steps whose execution is coordinated by a central orchestrator.When a client submits a workflow, the orchestrator creates a record for it in a data store then dispatches it to a worker for execution. Each time a worker completes a step, it sends the step’s outcome back to the orchestrator. The orchestrator checkpoints the output in its data store, then dispatches the next step. If a worker crashes or fails, the orchestrator dispatches its workflows to another worker, starting them from their last checkpointed step.In this blog post, we’ll argue that external orchestration is fundamentally overcomplicated. The core idea of durable workflows is to checkpoint program state in a database. But if durable workflows are about databases, then there’s no reason to have a separate orchestrator server. Instead, it’s simpler and more efficient to use the database itself as an orchestrator. To make this more concrete, we’ll focus specifically on building durable workflows on Postgres, because its popularity, scalability, and rich ecosystem make it an ideal choice.In a Postgres-backed durable workflows system, application servers directly communicate with Postgres to execute workflows instead of going through a central orchestrator. A client submits a workflow for execution by creating an entry for it in a Postgres workflows table. Application servers poll the table for workflows to dequeue and execute. As a server executes a workflow, it checkpoints the output of each step to Postgres. If a server executing workflows crashes or fails, another server can recover its workflows from their checkpoints.This design renders a central orchestrator unnecessary because application servers can coordinate through Postgres. Instead of relying on a central orchestrator to dispatch workflows to workers, servers cooperatively dequeue workflows from a Postgres table, using mechanisms such as locking clauses to ensure each workflow is dequeued by exactly one worker. Instead of relying on an orchestrator to checkpoint step outputs, workers checkpoint steps to Postgres themselves. If multiple workers try to execute the same workflow simultaneously, Postgres database integrity constraints let them detect the duplicate work on checkpoint and back off.Replacing a central orchestrator with Postgres (or another database) makes durable workflows fundamentally simpler. In particular, it means hard problems such as scalability, availability, observability, and security can be addressed using well-understood Postgres-native solutions.Scalability and AvailabilityThe scalability and availability of a database-backed durable workflows system are fundamentally determined by the underlying database. The system can scale horizontally by adding more worker servers, so its maximum capacity is determined by how quickly the database can process workflows. Similarly, workers are fungible and can freely recover each other’s state, so the system is available as long as the underlying database is available.When using Postgres specifically, this is beneficial because Postgres scalability and availability are well-studied problems with robust solutions. For scalability, a single Postgres server can vertically scale to handle tens of thousands of workflows per second, and further scaling can be achieved by using distributed (e.g., CockroachDB) or sharded Postgres. For availability, Postgres supports streaming replication with automatic failover and managed offerings provide multi-AZ deployments with high-availability SLAs out of the box. As a result, the decades of engineering work and research that have gone into operating Postgres at scale can translate directly to operating durable workflows.ObservabilityWhen using Postgres-backed durable execution, workflows and their steps are checkpointed to Postgres tables. This means observability is built-in: you can scan those checkpoints to monitor workflows in real time and visualize workflow execution. Postgres excels at this because virtually any workflow observability query can be expressed in SQL. For example, here’s a query to find all workflows that errored in the last month:A query like this might seem obvious, but it’s hard to overstate how powerful this is. It’s only possible because Postgres’s relational model lets you express complex filtering and analytical operations declaratively in SQL, leveraging decades of query optimization research. Many systems with simpler data models, such as the key-value stores used by popular external orchestrators, have no such support. By storing workflow and step data in Postgres tables and augmenting them with secondary indexes for fast analytical queries, you get efficient observability from your durable execution “for free.”Reliability and SecurityWhen using an external orchestrator for durable execution, both the orchestrator and its data store are single points of failure. Because they directly coordinate workflow execution, if either has downtime, the entire application becomes unavailable. Moreover, because they process and store workflow and step checkpoints, they likely have access to sensitive application data, meaning they must be hardened, access-controlled, and audited like any other piece of sensitive infrastructure. By contrast, the only point of failure in Postgres-backed durable execution is Postgres itself, and all workflow data is stored directly in Postgres and never transits any other system. If an application already depends on Postgres, adopting durable execution does not add any new points of failure to the system nor introduce new surface area to secure. Databases are already critical infrastructure, so it makes more sense to reuse them for orchestration than to add new critical infrastructure for it.Learn MoreIf you like building scalable, reliable systems, we’d love to hear from you. At DBOS, our goal is to make Postgres-backed durable execution as simple and performant as possible. Check it out:Quickstart: https://docs.dbos.dev/quickstart GitHub: https://github.com/dbos-incDiscord community: https://discord.gg/eMUHrvbu67 Share this post

InsightsRecent articlesThe latest in durable execution, AI workflows & more.DBOS ArchitectureMay 20, 2026Postgres is All You Need for Durable WorkflowsLearn the virtues of a Postgres-backed durable execution system and how it compares to external workflow orchestration systems.Peter KraftHow ToMay 11, 2026Building an Open Source Developer Experience Agents will LoveLessons learned and best practices we follow to make DBOS easier for AI coding agents to use. What worked, what didn't, and where things still break.Qian LiPeter KraftDBOS ArchitectureMay 5, 2026Spring into DBOS for JavaDBOS Transact for Java 0.8 is released. This article describes the new Spring Boot integration via a new Transact Spring Boot Starter package.Harry PiersonDBOS radically simplifies cloud application devops and deployment.

ProductsDBOS CloudDBOS TransactPricing PlansContact UsSolutionsCron Job PlatformDurable AI WorkflowsDurable Data PipelinesCloud ModernizationDevelopersDocsQuickstart GuideExamplesTutorialsCompanyAbout UsPrivacy PolicyTerms of ServiceCookiesCopyright © DBOS, Inc. 2025Build your reliable backend. Effortlessly.Contact salesStart your projectGet started with DBOSUse the open source DBOS Transact library, free forever. Pair it with DBOS Pro for premium tooling and support.Start for free

Explore plans

Follow our GitHub

Join our Discord

Get in touch

Subscribe to DBOS InsightsMonthly updates on durable workflow execution and observability.By subscribing you agree to with our Privacy Policy You've successfully subscribed!Oops! Please check your email and try again.ProductsDBOS TransactDBOS ConductorPricing PlansUse CasesCron Job PlatformDurable AI WorkflowsDurable Data PipelinesCloud ModernizationCustomer StoriesBristol Myers SquibbYutoriDosuAll storiesDevelopersDocsQuickstart GuideExamplesTutorialsLLMs.txtCompanyContact SalesBlogAbout UsOur TeamPartnersCareers© 2026 DBOS, Inc. All rights reserved.Privacy PolicyTerms of ServiceCookies Settings

Durable workflows are a method for building reliable programs by regularly checkpointing their progress to a database, allowing the system to recover from failures by reloading from the last completed step. While many systems implement this through external orchestration patterns, such as those found in Temporal or Airflow, this paper argues that external orchestration is fundamentally overcomplicated. The core concept of durable workflows relies on checkpointing program state within a database, suggesting that eliminating the need for a separate orchestrator and using the database itself for orchestration is a simpler and more efficient approach.

The proposed architecture centers on Postgres as the foundation for durable execution, leveraging its popularity, scalability, and rich ecosystem. In this Postgres-backed system, application servers directly interact with Postgres to execute workflows instead of relying on a central orchestrator. Clients initiate a workflow by creating an entry in a Postgres workflows table. Application servers then poll this table to dequeue and execute workflows. As servers execute workflow steps, they checkpoint the results directly into the Postgres database. This design avoids a central orchestrator by enabling application servers to coordinate workflow execution through the database.

To manage concurrency and ensure data integrity, application servers cooperate by dequeuing workflows from the Postgres table, employing mechanisms like locking clauses to guarantee that each workflow is assigned to exactly one worker. Furthermore, workers are responsible for checkpointing their step outputs directly to Postgres. If multiple workers attempt to execute the same workflow simultaneously, Postgres database integrity constraints are utilized to detect duplicate checkpointing attempts and manage back-off procedures. This approach replaces the need for a central orchestrator by distributing the coordination responsibility across the application servers interfacing with Postgres.

This shift results in significant advantages in scalability, availability, observability, and security. The scalability and availability of the system are fundamentally determined by the underlying database. The system can scale horizontally by adding more worker servers, and availability is maintained as long as the database remains operational. Postgres supports robust solutions for this, including streaming replication with automatic failover and multi-availability zone deployments offering high-availability service level agreements.

In terms of observability, storing all workflow and step data directly in Postgres tables makes observability native. Because Postgres uses a relational model, virtually any analytical query required for monitoring workflows can be expressed using SQL, allowing for complex filtering and analytical operations. This capability stems from Postgres’s decades of query optimization research, enabling efficient real-time monitoring of workflow execution by scanning the stored checkpoints. In contrast, systems using simpler data models, such as key-value stores common in external orchestrators, often lack this native support for complex analytical queries.

Regarding reliability and security, this model mitigates risks associated with single points of failure. By avoiding a separate orchestrator, the system eliminates a potential point of failure where downtime of either the orchestrator or its data store could halt the entire application. Moreover, since the workflow data resides directly within the existing Postgres infrastructure, the system does not introduce new critical infrastructure dependencies or new security surface area. This leverages existing, well-established database security measures.

Peter Kraft emphasizes that by utilizing Postgres for durable execution, the system achieves durability in a manner that is simpler and more performant. The goal is to leverage the strengths of the database to handle complex orchestration logic, making durable workflows as simple and performant as possible through database-native solutions.