Durable execution is still early. The pain points are real.

Introduction

Durable execution is becoming a product category, and it is still far from mainstream. Temporal is the established leader, Restate and DBOS followed with lighter runtimes, and long-running AI agents are now bringing the category a wider audience. What happens after a team adopts one of these engines, and why do teams that evaluate one decide against it?

We read what developers say about the three engines in public: Hacker News, Reddit, the Temporal community forum, GitHub issues, and each vendor's documentation and pricing. We build Dex, a durable execution engine, so we have a stake in the answer; the last part of this post is ours.

This is a qualitative review of public discussion, not a survey. Temporal has by far the largest pool of firsthand reports because it has by far the most production users. The methodology is at the end.

The complaints converge on five themes, whatever the engine

Read side by side, the discussion settles on five problems: changing code while runs are in flight, the learning curve, operating the engine, seeing what a run is doing, and cost, with AI agent workloads as a sixth, newer one. The shading below reflects how direct and how repeated the public evidence is, which depends as much on a product's age and user base as on the product itself.

Every engine shares one structural constraint: changing the code of a process that is already running

Each engine recovers a process by re-executing its workflow code against a recorded history or journal, and a long-running execution may have started under an earlier version of that code. Change the order or identity of the steps, and the replay no longer matches what was recorded. Temporal users describe it most often; Restate's contributors acknowledged the same limit in the launch thread.

All three vendors document a path through this: Temporal with patching and worker versioning, Restate with versioned deployments and shorter chained invocations, DBOS with patching and versioning as its upgrade guide describes. The constraint is not that in-flight runs break on every deploy. It is that every deploy that touches a workflow carries a compatibility question for as long as a run started on the old code is alive.

The learning curve leads the complaints about the largest engine; SDK fit leads them for the lightest

Before the durable model feels natural, a developer learns where a workflow ends and an activity begins, what determinism forbids inside a workflow function, and how workers and task queues are tuned. For Temporal, with the most surface area and the most users, that curve is the most repeated complaint in our scan.

For DBOS, a library added to an existing application, the sharpest critique is about how the SDK fits that application. The DBOS team had already received the feedback, and the dependency weight was reduced before the follow-up. It sits beside positive onboarding reports, including a developer who moved a job queue from Graphile Worker to DBOS in about half an hour with no infrastructure change. Incremental adoption and SDK friction are different stages of the same integration.

Operating the engine is a commitment of its own, and the lighter runtimes trade it for licensing questions

Self-hosting Temporal means a server cluster, a database, usually a search cluster, capacity planning, upgrades and worker tuning. Teams that already run Kubernetes and managed databases call it manageable; smaller teams call it a disproportionate commitment for the handful of processes that need durability. Restate and DBOS were built partly in response, and both draw praise for it. The complaints that follow are of a different kind.

The Restate objection came from an evaluator whose customers configure their own workflow steps, and who read the licence's notion of an application platform as a risk to that model; the repository still carries the Business Source License with an additional use grant. DBOS has since shipped a self-hosted Conductor under a proprietary licence. The accurate version of that complaint in October 2026 is not that the control plane cannot be self-hosted, but that the open-source library and the component that provides central visibility and recovery are two differently licensed products.

Observability is improving on every engine, and a business-readable view is still something you build

Every engine ships an execution UI, and in every case the engineers who use it have something to say about it.

Restate's early evaluators wanted execution-path diagrams rather than handler logs, and its 2026 releases answer much of that, most recently queue and wait-condition visibility in 1.8, released on October 15, 2026. What none of the three provides is a view of a running business process that an operator outside engineering can act on. Teams that need one build an application layer for it.

Cost complaints are specific to Temporal Cloud, and none of them come with a bill

Temporal is the only one of the three with a well-supported public cost complaint, and the only one with a published usage price to argue about.

What does Temporal Cloud publish as its price?

Temporal Cloud pricing page, read October 29, 2026. Worker compute is separate.

Neither speaker disclosed what they paid. For Restate and DBOS we found no generalized cost complaint. The cost no thread measures is the engineering time a self-hosted deployment absorbs, which is the number most teams are actually trading against.

AI agents are the newest source of friction, and they stress the parts of the model that were already hardest

An agent loop makes many small tool calls, changes its code often, and streams output while it works. Each of those stresses a replay-based engine: tool calls accumulate in the history, code changes raise the versioning question on every deploy, and streaming has to happen outside the history.

In the second report the handler had written to an external service before its worker was killed and the result reached Restate's journal, and the receiver could not deduplicate. That is the known edge of at-least-once retries: without an idempotency key or a shared transaction, no durable execution engine makes an external effect exactly-once. Agents call external tools constantly, which makes that boundary the common case.

What each engine's users complain about most

The order combines how often a theme recurs, how specific the reports are, and how much friction they describe. Severity estimates the practical impact on an adopting team, not incident frequency or satisfaction.

Why teams adopt durable execution anyway

The strongest statements in the record are not complaints. The same users who describe the learning curve and the tuning describe what the engine has done for them.

An engineer running a large, business-critical Temporal deployment wrote that they would adopt it again, complaints included. Across all three engines the complaints are about the cost of the model and the praise is about what it buys: durable retries, processes that survive restarts, a recorded history to debug from, and no distributed state machinery written by hand.

Where Dex stands on each of these

Dex is the durable execution engine we build, designed after years of operating the replay model at scale. Its unit is the Flow, a process written as Steps: a Step runs ordinary code and returns the next Step, and a Flow waits on Timers, Channels and RPCs without holding a thread and keeps its state in Attributes. The engine stores each Step's result as it completes, and that storage model, rather than a history to replay, is where most of the differences come from.

Dex, pain point by pain point

Changing the code of a running process

No replay. Each Step's result is recorded as it completes, and a running Flow continues on the new code from its next Step. No version branches, no old deployment kept alive.

Learning curve and SDK

A Step is ordinary code with its own retry policy and timeout, and no determinism rules, because nothing re-executes it. SDKs for Python, Go, Java, TypeScript and Rust.

Operating the engine

One binary that keeps its state in object storage such as S3, with no database or search cluster. Run it yourself or on Dex Cloud. Source available under the Sustainable Use License.

Seeing a run

A process graph generated from the code, with every run drawn on it: the current Step, what it waits for, inputs, results and errors. Business data in Attributes, searchable across runs.

Cost

Less infrastructure than a cluster with a database, and a published throughput and latency benchmark against Temporal on the home page. No total-cost comparison across engines exists yet, from us or anyone.

AI agent workloads

No history to grow, and Streams carry live output from a running Step. External side effects still need an idempotency key, as on every retry-based engine.

The comparison on our home page sets these differences beside the replay model row by row, and the AI agent example in the Dex repository shows the agent case end to end.