I have been observing the DBMS landscape as a professor for more than 50 years. During that entire period, the literature has talked about applications as being the main customer of DBMS services. Way back then, an application would connect directly to a multi-user DBMS with a two-tier architecture as noted in Figure 1. That was the structure of the early relational DBMSs in the 1970s and 1980s.
As workloads increased in size, a two-tier architecture had serious scalability limitations. Main memory was consumed by many copies of an application, each for a different user. In addition, DBMSs had trouble with the many connections that were required to the DBMS. Some sort of connection pooling was clearly needed. To solve these issues, a two-tier architecture gave way in the early 1990s to a three-tier one as noted in Figure 2. Here the application was split between presentation which ran at the top-tier, typically on a desktop computer, and the business logic which ran in a middleware application server. The bottom tier was still the DBMS. Also, the world wide web entered the picture in the early 1990s. Popular app servers for this era include Websphere, Cold Fusion, WebLogic, and Tomcat.
A three-tier architecture has several advantages over a two-tier one. First, multiple instances of the app server are typically run, and app servers generally multiplexed connections to the DBMS. This cut down on the number of connections the DBMS had to support. Also, one could have fewer copies of the business logic, which reduced main memory consumption, and the customer could spread the load over more than one physical server. Lastly, better scheduling of transactions could often be achieved by sophisticated queuing. By the mid-1990’s essentially all applications that required scalability ran with a three-tier architecture and used the Internet for connections between the client and middleware.
In my opinion, applications should no longer be the object managed by middleware servers. Rather they should be replaced by workflows as the unit of middleware management. The rest of this post will make the case for this switch in abstractions. We consider primarily applications that interact with stored data as opposed to pure computations. In the next three sections we detail some of the things that are different today from 30 years ago.
Agentic AI
In the last few years, large language models (LLMs) have been widely used in enterprise applications. Recently, it has been observed that better accuracy can be generated by adding computation around an LLM. This results in a multi-step workflow composed of steps, which is typically long running, because LLMs are computationally heavy. As such, an agentic workflow is a directed graph of processing steps, perhaps with loops. As with any long-running workflow, it is important to support durability, so that a workflow can be restarted from the last completed step if something bad happens (e.g. application crash, server crash, network timeout). Also, many agentic AI applications try something, decide it is not the right path, and then back-up and try something else. Again, durable workflows allow such backout to be very efficient. Lastly, if agentic AI is performing updates, e.g. buying something on your behalf, then the update must be unwound if the item is out of stock or the customer does not want to proceed for some other reason. Again, durability is desired for better efficiency.
Transaction management is a challenge for long running workflows, since they might hold locks for the duration of the workflow, thereby creating significant contention. Alternatively, they can be divided into multiple transactions. In this case, if things go south, then back out over multiple committed transactions is required. Sometimes, one can simply physically back out the changes of the transactions. However, in a multi-user context intervening updates from another user may require backing out to entail compensating for the updates processed. This was originally studied in [1] and considered in an agentic AI context in [2].
In summary, agentic AI results in workflows with long-running steps and requirements for durability and compensation that are not the same as ACID transactions. Obviously, one should run a server with these capabilities. As such an app server should be upgraded with:
- Workflow (graph) management,
- Durability
- Backout and
- Compensation.
We will term an app server with some or all of these added capabilities a workflow orchestrator. Example workflow orchestrators include Airflow, DBOS, and Temporal. In summary, agentic AI requirements suggest replacing an app server with a workflow orchestrator.
More Complex Business Applications
Many current DBMS applications have multiple steps in them. The canonical example is funds transfer in a banking environment where both the originator and the receiver run transactions. An even more complex example concerns the logic behind a website that sells bicycles, as noted in Figure 3. Here we see a workflow of four steps. First, one needs to check inventory to see if the model chosen is in stock. If so, the customer’s credit is checked to see if the vendor wishes to do business with this customer. If credit is ok, then the vendor accepts payment (say by credit card) and finally, the bicycle is shipped.
However, each step in this workflow can fail. The bicycle may be out of stock, the customer may have unacceptable credit, or may present an invalid credit card. Lastly, the customer may give the vendor a bad address for fulfillment. When a step fails, an alternate step may be tried (e.g. check another warehouse for inventory) or the workflow may be aborted (if the customer has bad credit).
Since each step is typically a transaction, often to a foreign service, aborting a workflow will require undoing (backing out or compensating for) committed transactions. Running alternate steps requires keeping track of the “state” of a workflow graph. In general, a workflow requires:
- Durability
- Step/state management
- Compensation
If one chooses to run an app server, then these facilities must be coded inside the application. On the other hand, in a workflow orchestrator, these can be delegated to the orchestrator, simplifying application construction.
Extreme Scalability
Large business-to-consumer applications (e.g. Etsy, Visa, Shopify, Walmart, etc.) are seeing orders of magnitude increased volume relative to 30 years ago. Of course, these use cases are examples of the issues covered in Section III. In addition, they usually require more sophisticated scheduling of workflows to avoid hot spots and stalls from long running workflows or transactions. In addition, the load on such systems varies a lot over a 24-hour day, and it would be highly desirable to have server elasticity. In other words, the platform should allocate resources as the load scales up or down. Again, these are requirements for a workflow orchestrator in these environments.
Summary of Workflow Orchestrator Benefits
In summary, a workflow orchestrator is an application server with some or all of the following features:
- workflow (graph) management,
- durability
- backout
- scale up-down and
- compensation.
A workflow orchestrator with these features has enormous benefits relative to standard application servers. First, the application is spared the effort of supervising control flow between steps. I claim there are less errors when control is factored out of a multi-step application. If the control flow changes, there is one place to make this alteration, and the application builder does not have to wade through application code to discover where to change it.
Moreover, the workflow graph is a handy visualization tool and can be the basis of a debugging or monitoring tool. Such tools are obviously not available in application servers.
Third, when errors happen (bugs, hardware faults, crashes, etc.) the application obviously fails. If it is treated as an application, then the application must be restarted. On the other hand, if it is treated as a workflow, then the workflow can be made durable by underlying workflow orchestration software. In this case the application is not restarted from the beginning but rather from the last completed workflow step. Especially, if steps are computationally intensive (as is often the case for agentic AI), then a great deal of computation cost is saved.
Moreover, durable workflows save important state to storage (DBMS, files, etc.). Think of these as checkpoints, if you like. As such, one can back up time by restoring a previous checkpoint. Such time travel is an important debugging tool, as noted in [3]. Obviously, such a facility is much more difficult without durability.
Applications sometimes “go off the rails.” This is especially true of agentic AI. When bad things happen, one must either put error logic into the application. Such logic could say, for example, “when things go wrong, then do X.” This results in a badly structured tangle of code.
If the application is replaced by a workflow, then it is the workflow that goes off the rails. In this case, a workflow step (or steps) will need to be unwound and a different path tried. These directives are external to the code of the steps, and lead to a more structured, understandable error path. Since the majority of many applications is error logic (up to 90% in some cases), a workflow is the preferred alternative.
Many agentic AI applications are read-only, i.e. they consult and integrate multiple data sources and generate an answer (for example, a personalized shopping recommendation). However, I expect this will quickly move to agentic AI taking actions as a next step (for example putting the recommended purchase into the user’s ecommerce shopping cart). This will turn agentic AI into a read-write world. In this case, the customer may refuse the recommended product, and the write will have to be unwound. Sometimes a simple physical undo will work, but sometimes a compensation must be performed. For example, the compensation for an increment is a decrement. A good workflow orchestrator will support user-defined compensations which it performs when necessary, relieving the user of the need to do this manually.
For reasons of simplicity, debuggability, monitoring, and the error path, a workflow is the preferred way to think about current applications. As such we should upgrade application servers with the capabilities discussed above. I.e. an application server should become a workflow orchestrator.
Obviously, a simple application can be considered a degenerative workflow. In a workload that is a mix of simple applications and workflows, the customer can get the benefits of workflow management for the workflows while also supporting the simple applications. In other words, in a mixed environment, the customer should also run a workflow orchestrator in preference to an application server.
DBMS as a Workflow Orchestrator
Every workflow execution requires a workflow orchestrator. It is a module which decides when a workflow step has all its required inputs and then causes it to be executed. Since all workflow state is stored in a DBMS by DBOS, it is natural to write the orchestrator as a DBMS application that stores and retrieves additional workflow execution state. This architecture has some enormous advantages. First, it eliminates the need to host, operate and maintain a separate dedicated orchestration infrastructure as is done by Temporal. Instead, we created an open source library that embeds workflow orchestration support within your application. There is no need for additional moving parts. In addition, there are no extra messages required by the DBOS architecture, resulting in dramatically superior performance versus the competition. In summary, the patented DBOS approach utilizes the database your application already accesses to perform durable workflow execution.
References
DBOS open source libraries (GitHub)
[1] Hector Garcia-Molina and Ken Salem, “Sagas,” Proc. SIGMOD 1987.
[2] Michael Stonebraker, Xinjing Zhou, Peter Kraft, and Qian Li, “Consistency and Correctness in Data-oriented Workflow Systems,” Proc. CIDR 2024.
[3] Qian Li, Peter Kraft, Michael Cafarella and Matei Zaharia, “R3: Record-Replay-Retroaction for Database-Backed Applications,“ Proc. VLDB 2023.