There is a quiet rebellion happening in how we build reliable software, and it is not coming from a new orchestration framework or a fancier queueing system. It is coming from a place we have largely taken for granted: the database itself. In their presentation, Jeremy Edberg and Qian Li make a compelling case for why external orchestrators might actually be the weakest link in your stack, and how leaning into the humble relational table can deliver durable execution with surprising grace. This is not about nostalgia for older tools; it is about recognizing that the operational overhead of a separate distributed system often outweighs its benefits, especially when your database already has the ACID guarantees you need.
The core argument is refreshingly contrarian. We have been conditioned to believe that complex workflows require dedicated orchestrators, that the harder the problem, the more specialized the machinery. Edberg and Li flip that assumption. They show how DBOS Transact uses standard tables, `SKIP LOCKED` queues, and unique primary keys to manage fault-tolerant AI workflows with minimal latency. The genius here is not in inventing a new distributed systems paradigm; it is in recognizing that your existing database, the one already running your business, is a perfectly good scheduler if you treat it with the right respect. This connects to a broader theme we have explored, such as how distributed training algorithms often overcomplicate what is fundamentally a coordination problem. If you can coordinate work with a simple `SELECT ... FOR UPDATE` instead of a dedicated message broker, you have just removed an entire class of failure modes.
What makes this approach genuinely practical, rather than just theoretically neat, is the focus on operational simplicity. The pitch is not that external orchestrators are always wrong; it is that they introduce a separate system that can fail, need patching, and require expertise. By compressing the workflow state into database tables, you get the same durability guarantees without the extra moving parts. This is a lesson that scales beyond AI workflows. We recently looked at how stateless Model Context Protocol removes session requirements to simplify scaling; the same principle applies here. The fewer stateful dependencies you have outside your core data store, the more resilient your system becomes. The database is the source of truth; why not let it also be the source of execution?
Our honest take is that this is the kind of architecture that sounds like it should not work, because our mental model of databases is too narrow. We think of them as passive storage, not as active participants in workflow coordination. But the talk demonstrates that with the right locking and indexing strategies, you can get the best of both worlds: the reliability of a database transaction and the flexibility of a workflow engine. If you are tired of babysitting a separate orchestrator that is only there to manage retries, this is worth your attention. The specific takeaway to quote: **"Your database is not just a place to store data; it is a durable execution engine waiting to be used."** The question this raises for us is not whether this works, but why we ever accepted the complexity of external orchestrators as inevitable. That is the assumption worth challenging next.