April 2026 Summaries

The text delves into the ongoing debate between using event-driven programming models and workflow architectures, particularly in the context of agentic AI applications that require coordination and error recovery due to their stateful and failure-prone nature. By presenting a hypothetical B2B e-commerce site as a case study, it contrasts the two paradigms: a workflow architecture orchestrates process steps sequentially, while an event-driven model uses independent event handlers interconnected by a message bus. The document employs a classification system to evaluate applications based on step dependency and the need for durability or atomicity, emphasizing that workflow architectures offer greater advantages in terms of understandability, error handling, and debugging. Inspired by Dijkstra’s critique of GOTO statements, the text argues that while event-driven architectures may suffice for independent, non-durable applications, workflow architectures are preferable for most multi-step applications, especially those requiring durability and atomicity, a view echoed by recent trends in AI framework design.

The blog post explores the scalability of a single Postgres server for executing durable workflows, focusing on its write performance, which is crucial for workflow execution. Through benchmarking, it is demonstrated that a single Postgres server can sustain a throughput of 144,000 writes per second, equivalent to processing 43,000 workflows per second, translating to 12 billion writes or 4 billion workflows per day, which is sufficient for most use cases. Experiments reveal that the main performance bottleneck is in the write-ahead log (WAL) flushing process, a common issue for write-intensive workloads. In scenarios involving Postgres-backed queues, the bottleneck shifts to lock contention in the workflow_status table, though distributing work across multiple queues can alleviate this to some extent. The findings suggest that Postgres scales well for durable workflows, and additional performance can be achieved by sharding workloads across multiple servers.

Serverless platforms like Google Cloud Run provide a fast and maintenance-free deployment option, but their stateless nature poses challenges for agentic AI applications, which require statefulness for executing multi-step workflows. These workflows often involve tasks such as writing to databases or calling external services, and interruptions can lead to inconsistent states, especially during long-running or bursty operations like customer support during peak times. Cloud Run's limitations, including its hour-long timeouts and lack of in-memory state persistence, make it unsuitable for stateful AI agents without additional tools. DBOS, an open-source library, addresses these challenges by storing workflow states in a Postgres database, enabling durable and observable workflows that can automatically resume after failures and scale with fine-tuned concurrency controls. Dosu, a team focused on AI-native knowledge infrastructure, successfully implemented DBOS to run tens of thousands of agentic workflows per hour on Cloud Run, overcoming scalability and reliability issues while maintaining lightweight serverless operations. Their integration included switching to instance-based billing, creating a dedicated Cloud SQL Postgres instance, and building custom Grafana monitoring dashboards, resulting in a resilient and scalable solution for their AI applications.

DBOS has introduced significant updates focusing on interoperability and privacy-preserving operations, enhancing its ecosystem with new features and integrations. Key advancements include cross-language workflow execution, enabling seamless interaction between different programming languages, and improved application versioning for better observability and control. The platform now supports enqueuing workflows from PostgreSQL UDFs and triggers, allowing closer integration with data processes. New primitives for concurrent workflows and steps, durable workflow delay scheduling, and automatic backfilling of cron schedules have been added to improve efficiency and reliability. DBOS Conductor has been enhanced with bulk workflow operations, custom metadata for executors, and a metadata-only mode for strict privacy, ensuring sensitive information remains private. The platform has expanded its partnerships, notably with LlamaIndex for durable agent workflows and Databricks for fault-tolerant AI agents, further enhancing workflow durability and observability.

DBOS has announced a collaboration with Databricks to integrate with Databricks Lakebase, aiming to enhance the reliability, reproducibility, and observability of AI agent behavior. This partnership addresses the challenges of building production-ready AI agents, which often encounter unpredictable failures due to their nondeterministic nature. By utilizing DBOS, a durable execution library, agents can maintain state through crashes and errors, enabling them to recover from the last completed step rather than restarting from scratch. This integration allows for the checkpointing of every agent action, creating a detailed record of the agent's progress, which aids in diagnosing and fixing issues. This approach not only adds fault tolerance but also helps in reproducing and resolving deeper issues in the agents' operations. With the ability to isolate and iterate on problematic steps, DBOS imposes a level of determinism on nondeterministic agents, facilitating a more efficient debugging process and reducing resource consumption. The partnership is designed to seamlessly integrate with existing Databricks-hosted agents and is supported by resources such as tutorials and community forums for users looking to implement these solutions.

The challenge of adding async support to a Python durable execution library lies in ensuring deterministic workflows for replay-based recovery, despite the inherent concurrency of async operations. Async Python employs an event loop, which is a single-threaded scheduler that runs tasks sequentially, allowing concurrency through task scheduling and yielding control via the `await` keyword. While asyncio allows for concurrent execution using functions like `asyncio.gather`, it introduces complexities in step execution order due to overlapping tasks. To resolve this, tasks are deterministically ordered by assigning step IDs before any awaited operations, ensuring a consistent execution sequence that can be accurately replayed during recovery. This approach leverages the predictable nature of the single-threaded event loop, allowing developers to create concurrent and safe workflows without the unpredictability of parallel threads. Understanding these subtleties is crucial for developing reliable Python libraries and systems that effectively utilize async capabilities.