DBOS challenges industry standard by advocating Postgres for durable workflow orchestration
The company contends that leveraging PostgreSQL’s native capabilities for checkpointing and coordination eliminates the need for central servers, streamlining architecture for investors and developers alike.
DBOS has published a technical argument on Hacker News asserting that durable workflows should be implemented directly on PostgreSQL rather than relying on external orchestration systems such as Temporal, AWS Step Functions, or Airflow. The company contends that the prevailing model of using separate orchestrator servers is fundamentally overcomplicated, introducing additional points of failure and security risks that can be avoided by using the database itself as the coordination layer.
Durable workflows operate by regularly checkpointing program progress to a database, allowing systems to recover from crashes by reloading from the last saved state. Traditional implementations delegate this coordination to a central orchestrator that dispatches tasks to workers and manages state records. DBOS argues that because the core requirement is database-based checkpointing, maintaining a separate orchestrator server is redundant and inefficient.
Under the proposed architecture, application servers communicate directly with PostgreSQL to execute workflows. Clients submit tasks by creating entries in a Postgres table, which servers poll to dequeue and process. This approach uses database locking clauses to ensure exclusive access and relies on Postgres integrity constraints to detect and prevent duplicate work, effectively removing the central dispatcher from the equation.
The company highlights that this design leverages PostgreSQL’s existing scalability and availability features. A single server can handle tens of thousands of workflows per second, while horizontal scaling is achieved by adding worker nodes limited only by the database’s processing speed. Availability is maintained through established mechanisms such as streaming replication with automatic failover and multi-AZ deployments, allowing decades of database engineering research to apply directly to workflow management.
By storing workflow data directly in Postgres tables, DBOS claims observability becomes inherent and powerful. Because virtually any workflow query can be expressed in SQL, operators can utilise relational models and secondary indexes for real-time monitoring and analytical filtering without the overhead of separate data stores. This contrasts with key-value stores often used by external orchestrators, which lack comparable declarative query capabilities.
Security and infrastructure complexity are also cited as key benefits. External orchestrators represent additional critical infrastructure that must be hardened, access-controlled, and audited, creating new surface areas for potential compromise. In contrast, a Postgres-backed system introduces no new points of failure if the database is already in use, as all workflow data remains within the existing database layer and never transits other systems.
DBOS concludes that replacing a central orchestrator with a database simplifies the architecture while addressing hard problems in scalability, availability, and security through well-understood, native solutions. The company invites developers to explore its Postgres-backed durable execution framework, positioning it as a simpler and more performant alternative to established orchestration tools.
