Article: Implementing Durable Workflows on Postgres without an External Orchestrator

Durable execution does not require a dedicated orchestrator like Temporal or AWS Step Functions; a relational database you already operate can play that role and remove a stateful, external system from your critical path. SELECT ... FOR UPDATE SKIP LOCKED turns an ordinary Postgres table into a concurrent work queue where each row is claimed by exactly one worker, with no message broker, leader election, or external lock service. Making step checkpoints a primary-key constraint lets the database enforce idempotency, so a step that reruns after a crash reads its prior result instead of repeating a side effect. Crash recovery can be implemented with a simple lease-and-sweeper pattern, where workers heartbeat the rows they own and a periodic query re-enqueues any execution whose lease expired. Storing workflow state in your primary database makes observability a plain SQL query and collapses reliability and security to one dependency. When we started building Kestrel Workflows (deterministic workflows for automating incident response, cloud provisioning, CI/CD, and developer requests), we hit the problem every automation system eventually hits. Our workflows had to be durable and survive all types of failures. A workflow can be…