Developers building reliable distributed applications face a familiar headache. They write business logic only to watch it fracture across separate systems for state, queues, and orchestration. Partial failures pile up. Idempotency checks multiply. Reconciliation jobs run in the background hoping to clean up the mess.
But a different approach has gained traction. Keep workflow state right next to application data. In the same Postgres database. Updated together in one transaction.
Peter Kraft and Qian Li laid this out clearly in a post for DBOS on June 15, 2026. “When workflow metadata and application data live in the same Postgres database, they can be updated in the same database transaction, which simplifies problems like workflow task idempotency and atomicity,” they wrote. The idea sounds simple. Its effects run deep.
Consider a basic banking operation. Credit an account. The step must run exactly once. Traditional workflow engines store orchestration metadata separately. A crash after the credit but before the checkpoint leaves you guessing. Retry the step and risk double crediting. Or build elaborate deduplication tables.
Co-location changes the equation. The workflow checkpoint and the account balance update happen inside one Postgres transaction. Commit both or neither. The database handles the hard part. No extra code. No drift between systems.
This pattern extends further. Take order processing. A customer submits an order. The system records it and notifies the warehouse. In separate systems the notification might fire while the order write fails. Or vice versa. Developers reach for the outbox pattern. Write both to the database then poll and send. Add another service to manage that polling. Monitor it. Debug it when messages get lost.
With co-located state a user-defined function can enqueue the notification workflow directly in the same transaction as the order record. The DBOS article describes how this eliminates the outbox entirely. One database. One source of truth.
The broader concept comes from DBOS itself. The project, founded by database pioneer Michael Stonebraker and Databricks co-founder Matei Zaharia, treats the database as the foundation for execution. Workflow checkpoints live in Postgres tables. Application code runs steps that can be transactional by design.
Earlier this year the team pushed the idea even harder. In a May 20, 2026 post titled “Postgres is All You Need for Durable Workflows,” Peter Kraft argued external orchestrators add unnecessary complexity. “External orchestration is fundamentally overcomplicated,” he wrote. Instead application servers poll a workflows table directly. They dequeue with locking clauses. They checkpoint outputs back to the same database. Recovery pulls from those checkpoints. The only failure point sits where organizations already invest heavily: their production database.
That post, available at dbos.dev, details how a single Postgres instance can handle tens of thousands of workflows per second. Scale by adding workers or moving to distributed Postgres variants. Observability becomes SQL queries against workflow tables. Find every failed run from last month. No new dashboards to wire up.
Recent updates show the approach maturing. The June 2026 release notes highlight pluggable data sources, atomic bulk messaging, and improved observability tools. OpenMetrics export lets teams feed workflow data into Datadog or Prometheus without custom agents. Role-based access control appeared for the console. Bulk workflow forking from the UI. A plugin for Google’s Agent Development Kit brings durable execution to AI agents.
Those notes at DBOS’s blog tie many improvements back to the same principle. “When a workflow step performs database operations, running it as a transactional step guarantees exactly-once execution.” Atomic bulk sends roll back the entire batch on any failure. The database transaction enforces consistency across workflow lineage and application records.
Industry conversation reflects growing interest. On X, developers have praised the simplicity. One user noted that with Postgres, DBOS keeps workflow state in your own infrastructure. Another highlighted how the system avoids external orchestrators entirely. Recent posts from the DBOS team showcase redesigned visualizations in their Conductor UI, multi-dimensional filtering, and aggregate views that make sense of thousands of running steps.
The approach addresses classic distributed systems headaches. Idempotency. Exactly-once delivery. Atomic multi-system updates. Traditional tools force developers to make steps idempotent by hand. They require careful error handling for partial progress. They introduce new infrastructure that must be secured, scaled, and monitored separately.
Co-location removes those layers. The database already knows how to provide isolation, durability, and atomicity. Why replicate that logic across a fleet of services?
Of course challenges remain. Not every operation fits neatly in a database transaction. Long-running external API calls still need careful step design. Teams must consider Postgres performance under heavy workflow load. Yet the DBOS team reports production use at scale, with billions of workflows processed monthly in some cases.
Partners have taken notice. A collaboration with Databricks aims to make agentic AI more reliable through database-backed orchestration. The Google ADK integration promises production-grade durability for AI agents using a database organizations already own and trust.
Look at the architecture. Workflow inputs and step outputs sit in system tables. Recovery replays from the last successful checkpoint. Communication between workflows uses database primitives like LISTEN/NOTIFY for low latency. Everything stays within the transactional boundary.
Developers writing Python, Java, or Go code annotate functions as workflows or steps. The runtime handles checkpointing transparently. Crashes, restarts, or even code updates in some cases can resume without losing progress.
This model echoes ideas from the original DBOS research. Store operating system state in a high-performance database. Write services in SQL and stored procedures. The cloud-native version adapts that vision to modern application development.
Critics might ask whether Postgres becomes a bottleneck. The team counters with vertical scaling numbers and options for sharding or CockroachDB. Observability improves because SQL already offers powerful analytics. Security stays tight since no new data paths cross the network beyond what the database already manages.
Recent community projects extend the concept. Open-source dashboards read workflow tables directly without additional agents. Integrations with tools like Bauplan combine durable orchestration with data processing for AI workflows.
The pattern offers a pragmatic path forward. Organizations already run Postgres. They understand its operational characteristics. They have backup, replication, and monitoring solutions in place. Adding durable workflows need not introduce another critical system to baby-sit.
Instead of fighting partial failures across boundaries, developers let the database enforce correctness. They spend less time on plumbing. More time on business logic.
That shift matters as applications grow more complex. Event-driven systems multiply. AI agents chain together dozens of steps with human-in-the-loop decisions. Reliability becomes table stakes. Approaches that simplify correctness at the foundation gain appeal.
The DBOS team continues refining the experience. June updates brought better support for Spring Boot, dynamic queues, and debouncers. Workflow communication primitives expanded. The Conductor console now surfaces summaries and graphs at a glance.
Yet the core insight stays constant. Put the state where the data lives. Let transactions do the heavy lifting. The resulting systems prove simpler to build, easier to observe, and more reliable in production.
Many teams still default to separate orchestration layers. They accept the complexity as the cost of durability. Others have started questioning that assumption. One database. One transaction. Fewer moving parts.
The results speak for themselves in reduced operational toil and stronger guarantees. For organizations already invested in Postgres, the question is no longer whether to add durable execution. It is how quickly they can start co-locating their workflow state with the data that matters most.
WebProNews is an iEntry Publication