{
  "id": 7305339,
  "title": "Article: Implementing Durable Workflows on Postgres Without an External Orchestrator",
  "url": "https://urgent.news/2026/09/14/article-implementing-durable-workflows-on-postgres-without-an",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-14T11:00:00.000Z",
  "source": {
    "name": "InfoQ",
    "slug": "infoq",
    "url": "https://www.infoq.com/articles/durable-workflows-postgres/"
  },
  "original_language": "en",
  "account": "In the pursuit of building Kestrel Workflows, a system designed for automating various tasks such as incident response, cloud provisioning, CI/CD, and developer requests, the team faced the universal challenge of ensuring that workflows remain durable and resilient to failures. This requirement led them to the concept of durable execution, a principle that involves checkpointing a program's progress to an external system like a database. If a process were to terminate, another could load the last checkpoint from the database and resume from the last successfully completed step, akin to autosave functionality in video games but for backend code. Initially, the team contemplated using an external orchestrator like Temporal or AWS Step Functions to manage this process. However, they eventually decided against this approach due to the additional complexity and resource requirements it would bring. An external orchestrator would necessitate the deployment, security, monitoring, and upgrading of an additional stateful system, acting as a single point of failure within the workflow process. Furthermore, it would introduce a new data model, typically a key-value store optimized for workflow states, which could complicate ad-hoc analysis compared to querying their primary system, Postgres. The team reasoned that if Postgres was already their system of record and had been optimized for scale, why not leverage it as the orchestrator instead? This realization led them to explore the possibility of implementing durable execution directly within Postgres. In their solution, there is no dedicated orchestrator process; each application server runs an embedded durable workflow library that interacts directly with Postgres. Workflows are triggered from various sources such as PagerDuty alerts or GitHub webhooks, and each trigger is recorded in a workflow_executions table. Servers then poll this table to claim work and checkpoint the output of each completed step back into Postgres itself. The key to ensuring safety and achieving exactly-once processing lies in the use of a Postgres clause known as FOR UPDATE SKIP LOCKED, which locks rows claimed by a worker and prevents other workers from interfering. This mechanism ensures exactly-once processing, allowing two servers to poll the same table simultaneously without the risk of duplicate executions. The authors illustrate how their implementation can be executed within a short transaction that not only flips the status and writes the lease but also handles the critical task of step checkpoints. They utilize Postgres' integrity constraints, enforcing uniqueness on the (execution_id, step_id) pair in the operation_outputs table. When a worker finishes a step, it records the result as an upsert, ensuring no duplicate entries are made. If a recovering worker encounters a step that has already been completed, the unique constraint prevents it from inserting a duplicate checkpoint, and instead, it returns the previously stored result. This approach relies on Postgres' primitives to enforce idempotency rather than relying on custom application code. For production implementations, the article highlights a few considerations. The use of integrity constraints in Postgres allows the system to enforce idempotency, avoiding the need for custom application logic to manage duplicate steps. Additionally, the article explains how workers communicate their ongoing tasks through lease columns, which are used to track the progress of running executions. If a worker dies unexpectedly, perhaps due to reasons like OOM crashes, node drains, or pod evictions, its lease is not renewed, and a sweeper process can step in to reset these stuck executions. The article concludes by emphasizing how the Postgres-based durable execution model simplifies failure recovery and enforces concurrency and idempotency through database primitives, ultimately reducing the complexity and overhead associated with maintaining a separate orchestrator system.",
  "summary": "Postgres can serve as the durable state store and coordination layer for workflows, eliminating the need for an external orchestrator. SKIP LOCKED enables concurrent work processing, primary-key checkpoints enforce idempotency, and leases support crash recovery. Workflow sleeps and human approvals can also be persisted as database state and survive restarts. By Raman Varma",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}