Can someone shed some lights on what temporal does?
Their blog says [1]
Durable Execution offers three key benefits:
It improves application reliability by providing fault tolerance.
It simplifies code by allowing it to focus on the goal instead of potential problems.
It accelerates development by eliminating the need to write complex error-handling logic.
So... like exception handling? or something like erlang's let it crash mantra?
Why is it such a big deal? Genuine question, not trying to be snarky
It’s an async job runner that scales well. Yeah they advertise a lot of fancy features, but really what they are selling is solid failure-resistant infra. Companies could set the same thing up with an in-house team, but it’s pretty great to be able to click a button and start running workloads at tens or hundreds of thousands of RPS without needing to figure out the internals.
Not the same thing, because celery and the like are sdk-level abstractions that need you to plug in your own queue (usually Redis, Kafka) and all other components. The Temporal server deployment includes the full control plane, queue, persistent database, UI and everything else. So you only need to manage your worker boxes.
Durable execution comes with overhead that you'll need to determine whether or not fits your use case. If you're looking for raw speed then durable workflows are going to be a steep trade off. Most workflows should be durable by default, though, so it is more the rule than the exception.
Say you've got a process that spans a bunch of services and touches the real world. Some ecommerce check out for example.
You need to reserve some inventory, charge a card, eventually email a customer and steps can go wrong. So you have queues, and retries and ways to back things out, undo changes.
To my understanding, Temporal's idea is to factor that part out, the queues and retries, and offsetting actions, so you write the logic and not the workflow orchestration.
Basically, a multi-step event handling system, where the data could be spread across multiple databases/systems, so there's no way to rollback a transaction atomically across all the databases. Instead, you explicitly codify "compensations" to undo your previous commits so that you eventually end up in a consistent state.
Temporal is the orchestrator/framework/library to implement the above in an easier way.
IME, it works, but at the cost of a pretty large amount of overhead, both in performance and (I think more importantly) cognitive.
Honestly I never did come to a satisfying conclusion on whether I thought it was worth it. The teams I worked on that used it found it neither simple nor easy to use, and I was never sure whether we were really reaping the benefits of correctness in the face of failure at the scale we were running. We eventually migrated everything off of it, and everyone was happier, but perhaps (probably) we had more lurking bugs in distributed failure cases. But to my knowledge we never tracked down an incident to the kind of problem that temporal solves.
I guess I'd say that I like durable execution (or at least temporal specifically, it's the only system like this that I've used) in theory, but not really in practice.
Yeah, I’ve seen it working. It does work well to implement a multi-system transactional workflow broken down into retryable steps. So, eg, if you are operating a SaaS and need a workflow for new customer signup to wait for multiple steps that might last for hours or days like: validate credit card info, wait for email confirmation, add entries to customer database, set up workspaces in downstream systems, spin up cloud resources, initialize systems, notify customer, start billing cycle, etc. and if any step fails, you might want to retry or send alarms or internal notifications, or roll back other steps, or kick off other workflows. Then you can define all of that, in code. Each step can be different runtimes run on different worker systems, etc, all coordinated through a central database.
You can scale the workflows up and down to as complex or simple as you want for whatever your business is. The example above is one I’ve seen, but it works on a smaller scale as well. But you have to write the implementation code in very specific ways to get the benefits, and the overhead ends up being very difficult to plan and reason about, and a lot of business logic actually gets hidden amongst the weeds of the tool’s overhead.
In concrete terms if your app has functions that do very little work but run for hours or days at a time blocking on external resources, and it is acceptable to add 100+ms latency + a serialization boundary to every function call, it is acceptable to take on a bunch of other tooling complexity, and you are willing to sacrifice verifiability of the code, then it might be a fit. In those situations the structure of it (or DBOS or similar) can help standardize that part of your app. Unlike a regular state machine based approach it's easier to represent branching logic and so forth in imperative code. I think its popularity is like the Mongo NoSQL fad, it looks convenient up front but in practice is very painful in most situations. Having used it a fair amount I would recommend starting with actors and state machines, especially in this age of robot code where it's easier to apply heavier approaches to testing in verification.
Asking what temporal is? The founders (Maxim Fateev and Samar Abbas) originally made Amazon Simple Workflow Service (SWF), Azure Durable Task Framework (DTF), and Uber Cadence. Temporal is the latest in the long line of workflow systems they've built. It's a task engine with state, recovery and highly scalable. It's cool stuff, and it simplifies many business workflows when it comes to recovery and scaling. There are many similar systems on the market today that mimic durable functions but Temporal is arguably the best.
When you write traditional distributed systems/cloud native code you have to handle all the failures and retries somewhere. Anyone who's run an Ansible playbook or similar and had a failure halfway through leave the state of the systems in a weird half-state is familiar. Or dealt with spot preemptions or nodes failing or getting unlucky with OOM killer or hardware failures or a myriad of other failure modes.
In Temporal, you use their SDK to mark which code is either:
- Deterministic without external dependencies on network, disk, clock, etc.
- Non-deterministic (e.g. accesses a filesystem, dependent on clock time, talks over the network)
You can write the code without handling flakiness or retries and the Temporal control plane handles all the progress tracking and retries for you. Progress is tracked at the individual line of code for deterministic code, or for non-deterministic code, tracked at function boundaries defined by the programmer. You buy into more complexity upfront, but it makes the application code way simpler and easier to manage overall.
They do a lot of other cool stuff on top of all this, and their Temporal Worker Controller architecture is particularly well suited to running massive scale processing/AI workloads on Kubernetes (handles a lot of stuff like autoscaling without interrupting work, rainbow version rollout, etc.)
temporal makes you split up your async tasks explicitly into a message (a request to fulfill a task, thrown up to a temporal server), and a task handler (pulling a tasks-request from a queue, from the temporal server), rather than both wrapped in a vanilla request/response cycle.
temporal centralizes all the error handling, retry handling, ... some web pages to manage failed, pending tasks.
it's been good for us, but a real step function in complexity of the app.
This is a rough explanation, but generally it does a couple of things that are helpful.
Functionally, it's a "workflow" runner (ex - you can mostly treat it like a queue, where you've got workers that are picking up work to do).
But it wraps a couple of pretty handy features on top like:
- It preserves most arguments to actions, and it makes system details deterministic for retries (ex you can re-run a workflow at a later time, and temporal will make sure the code sees details like date and time as though it were the original run, and will yell at you if you try to write code that won't be deterministic on retries)
- It supports very long waits easily. (ex - very easy to have a workflow do a couple things, wait a week, then do some more things).
- It has decent profiling and UI tools
- It can "restart" a failed workflow deterministically from the step at which it failed (using details from the original point)
---
Basically - it's a background worker service that's put a lot of time and thought into ways to handle failures better.
It absolutely still has some considerable pain points though, and I find it difficult to use for larger tasks (ex - their message gRPC size limit of 4mb is a b*&^% to work around, since it often breaks a lot of the utility they provide, and the history cap at 50mb is also really painful in certain situations.)
Really - I think it was just the right tool at the right time to make calling LLMs with long waits relatively easy and somewhat foolproof.
Another cool thing is it handles version rollouts. Say a customer started some kind of business process on v1.1 of your code, and then you deploy v1.2. You can configure whether that customer should continue that process on v1.1 - even if it's something that takes a long time in the real world - or whether they should be upgraded to 1.2. And it's not just one version but you can do this with an entire rainbow of versions across your business (think A/B testing, custom workflows for different use cases, lots of dev and staging environments, etc.)
Thank you for all the explanations. I think I have better understanding now.
Another question, at what scale (in terms of number of services, and maybe throughput? what other dimensions?) should we start considering using temporal?
I think scale is less important than other considerations. For me the biggest motivator is when the use case prefers doing something exactly-once, the downside risk of failure is high, and robust failure handling is moderately complex. The canonical example I use is healthcare communications; others use payment/fulfillment.
Also having a unified control plane is handy even at a pretty small scale if your alternative is going full “cloud native” on hyperscaler microservices. The ability to see what’s happening when and where across a single workflow run is a dream compared to all the traditional logging approaches I’ve seen.
Absolutely love temporal, but pretty shocked to see they have a $12.55B valuation.... feels nuts?
We're using temporal as the foundation for agents running on our platform doing accounting work for clients, it's proven extremely effective and I love how durable workflows are within temporal.
+100 on the technology, but realizing they are also VC funded makes me a little more cautious when it comes to vendor lock in.
> Our annualized revenue run rate is up more than 200% year over year, and net dollar retention's stayed above 200% since February. In August alone, the platform processed 1.9 trillion billable actions, up more than 350% year over year, while open source installs passed 43 million, up 134% since December 2025. We're now working with more than 4,300 paying customers, up 139% year over year, including OpenAI, Snap, NVIDIA, and JPMorgan Chase.
Temporal doesn't run your AI compute for you, you bring your own hardware on prem or in your cloud account or whereever. Their SaaS is a control plane to coordinate and orchestrate the workers.
Because the hard part of running it is making it highly available despite the inherent fallibility of distributed computing, which is an infrastructure problem, not an AI coding problem.
Temporal is fully open source, you can run the entire thing on your laptop or your own server. People pay for the SaaS anyway, because dealing with the distributed computing problems is hard.
(There are some other projects inspired by Temporal as well, but if you want to run something in-house, you're probably funding a minimum of 2-3 engineers to handle on-call, and for that price the SaaS is competitive).
A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remotely on a worker. Restate has a lean deployment model with a single binary that can be deployed multiple times to have a highly-available cluster (potentially spread across multiple regions). It is used for large-scale production clusters, and so lightweight here does not mean less reliable than Temporal.
You can do the same things with Temporal like sleep for months etc. You can learn more here: https://restate.dev/vs/temporal
* local: executed in the same process as the orchestrator code. Many local activities can be executed locally before their results are sent to a backend server in a single RPC call.
* task queue based: executed by a pool of worker processes that poll from the queue. This is the most flexible model as it supports flow control, priorities, fair queueing out of the box.
* eager dispatch: task queue based but executed locally if possible as a performance optimization.
Temporal also supports stand alone activities that are invoked without a workflow and dispatched through a task queue.
Restate only supports local activities (using Temporal terminology).
I wouldn't call it a "more flexible programming model".
Restate made several decisions I consider questionable for the system's availability and stability, like pushing work to handlers instead of dispatching it through a queue. Any design decision has tradeoffs. It would be nice if you mentioned these trade-offs in your posts instead of making claims that sound like pure marketing.
Sorry, but this is incorrect (Restate founder here)
(1) You can model the equivalent of local activities and activities that run on other workers in Restate.
A local activity is a step in the workflow function. An activity supposed to run on a different worker is a function called by the workflow function. Since these calls are just Restate events, exactly-one, suspendable, this gives you a full-fledged workflow/remote-activity pattern. Including concurrency, separate retry policies, etc.
(2) Restate steps commit individually, unlike local activities.
Imagine a two-step workflow, where you want one step durable before starting the second. Account withdrawal before deposit. Restate steps allow you to do that, each step is durable committed before the next step runs.
Per Temporal's own docs, Temporal Local Activity results become durable only when the enclosing Workflow Task completes. That's different than Restate, which can durably commit every individual ctx.run before proceeding to the next step.
Making actual durable commits fast, so you can have sequences of fast durable steps building on each other is super valuable. If an agent can commit the guardrail evaluation in low milliseconds before it starts the tool call, that's great, do it. If committing this involves dispatching another workflow or activity task, the consideration is harder.
When we see someone migrate a Temporal workflow, they often end up using many more durable steps in Restate than they used activities before.
(3) Why do we consider it flexible?
(a) Virtual Objects: Keep state around across the workflow, without doing tricks like "keep the workflow running, signal only, continue_as_new" after a while. Virtual Objects are a natural way to model concurrent stateful entities.
(b) non-workflow communication patterns: We have seen users build lot's of different patterns. It can get as crazy as graphs of functions/objects sending each other durable messages. All end-to-end idempotent (or exactly once, for Virtual Object state). That is outside the hierarchical workflow/subworkflow/activity abstraction.
(4) availability and stability
I don't know where the perception with stability comes from, Restate pushes some pretty high volumes for customers, like 100k+ actions/sec.
The push model in Restate is internally dispatched through queues as well. The application just don't see it as task queues. Limits are implemented through virtual-queues in Restate 1.7.
-----
Of course the systems make different trade-offs. The Restate design (vqueues, push model) is took us longer to build than a task queue model would have, because it puts more work onto the dispatcher that is otherwise handled just implicitly by the worker pools.
But once it is there, it is sooo nice, in how easy it integrates into infra, and how it can handle flow-control with high hierarchical limits in ways I genuinely haven't seen in any other system achieve (see https://restate.dev/blog/announcing-restate-1-7 )
Might not be par for the course for HN, but gotta drop a link with a light joke, with the background of the money grubbing guy (Temporal founder here) sucking up venture capital like vacuum cleaner who tries to argue he’s intellectually superior in a brag thread about his Company over a competitor (with significant OSS accomplishments) who is attempting to make the world a better place with a freely available primitive that isn’t just available to dev teams at mega teams at Netflix and OpenAI etc.
Hmmm, that feels not very nice, tbh. I have big respect for what Maxim and the team built, and both systems are essentially open and free (publish code and are free to use).
Do you realize that Temporal is fully open source under the MIT License, while the competitor is under BSL?
I certainly don't think I'm superior to them in any way and have great respect for the very capable team they are. We know each other personally. I even presented at the Flink conference while at Uber.
My message is that I'd prefer a more technical discussion of the merits of our products rather than simplified marketing attacks.
How does that compare to Inngest? As I understand it it also executes inline and has a streaming connection to the inngest server. We ended up going with them over temporal because it was so much simpler operationally, but restate seems even lighter. I can appreciate how it's hard to tackle the enterprise market, but the temporal solution feels so bloated I really hope the industry can standardize on some simpler patterns
The way it works is that Restate supports suspending workflows that sleep for months and later (once the sleep finishes) resumes them at exactly this point. Technically, this is the same process as resuming a crashed workflow.
While the workflow is actively doing work (like calling other services, accessing state or interacting with external services, for example) the server is connected to the workflow deployment via a low-latency bidirectional streaming connection to receive and acknowledge progress that the workflow makes. That way the workflow can finish as fast as possible.
A nice side effect of this model is that you can co-locate your workflow with expensive resources, such as a sandbox, which should be used by all durable actions that the workflow executes. The reason this works is because Restate can inline durable steps (what would be modeled in Temporal as activities, I believe).
If a handler starts a sleep/human approval/RPC call, or so, then this timer/promise is persisted in Restate's journal. Restate does the waiting. The handler process itself can suspend (e.g. on a serverless function), and the bidirectional connection is closed. Once the timer fires/approval comes in, Restate re-invokes the service with the journal of previously completed steps, and the service can replay to the exact point in the code where it suspended and continue from there. Restate is like a DB for journals, so you can sleep for as long as needed, also months.
So you have fast persistence of events while a handler can make progress, and suspensions while waiting.
I guess the confusion is that it doesn't have to be one single persistent stream.
While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (typical durable execution style).
That gives you the best of both worlds: same long-running workflows with long sleets and suspensions, but also ability to add steps with few ms overhead only.
The responses to this thread seem to be from people who are familiar with Temporal but haven't ever actually used Restate. They're both durable execution platforms, with differences mostly around how abstractions are organized and how orchestration of work happens (Temporal has you setup worker pools that pull from a queue while Restate pushes to service handlers). If some of your infra runs on serverless providers, Restate will often be a more natural fit.
Sure, Temporal is more mature and battle-tested, but Restate is quite nice and I honestly prefer it in most cases.
EDIT:
I started drafting this reply before seeing someone from the Restate team chimed in.
Those two don't really compare. Temporal has been around 3 years longer and is a much more heavyweight system. Temporal can support workflows that sleep for months at a time and still reliably finish.
I'm sure there is a place for restate.dev, but it isn't in the same place as Temporal.
Like Temporal, Restate supports workflows that sleep for months at a time and let's them reliably finish.
It actually does many more useful things. For example, you can have services that remember state across invocations and there is no need for continue-as-new.
Since Restate allows inlining durable steps into your workflow, it is very easy to co-locate your workflows with expensive resources such as sandboxes or other per-node resources. And the nice thing is that each durable step is really cheap and adds only minimal overhead.
AI workflows are a convenient fit for temporal, their platform is great for much more than just those. It’s an elegant and easy to use solution for a lot of workflow needs.
That's fair, but they are also a great fit for Restate. For example, Replit migrated their whole coding agent from Temporal over to Restate, a pretty big setup.
I understand that Restate and Temporal look similar from a superficial perspective but Restate is not only a durable execution engine but a durable runtime that also provides consistent state and reliable communication. These are the building blocks to build reliable agents and applications w/o having to fit them into a workflow-activity like model. If you want to learn more about how Temporal differs from Restate, check out https://restate.dev/vs/temporal.
Mostly C#, as I see your Rust SDK is under development.
Unfortunately it appears someone vibe-coded a port of the Java SDK for .NET and namesquatted the `Dbos.Transact` package on NuGet [1], making it look like an official SDK. It's also not a very good port, mirroring the Java implementation instead of using idiomatic C#.
If you ever plan on releasing a .NET library, I suggest opening up a dispute resolution [2] with the owner (it really is just an email to the guy, CCing NuGet support) and reserving the `Dbos` prefix [3].
No. A huge selling point of these code-first workflow engines is that they make writing durable workflows a lot like writing non-durable code, to the maximum extent that the language allows, such that the workflow orchestration disappears.
That is, they require good taste and opinionated API design first, porting skills second. The SDK for each language ends up being substantially different.
Frontier models are not very good at this yet. I've tried. Ultimately I couldn't justify the effort when there are other workflow engines out there.
Can someone shed some lights on what temporal does? Their blog says [1]
Durable Execution offers three key benefits:
So... like exception handling? or something like erlang's let it crash mantra?Why is it such a big deal? Genuine question, not trying to be snarky
[1] https://temporal.io/blog/what-is-durable-execution
It’s an async job runner that scales well. Yeah they advertise a lot of fancy features, but really what they are selling is solid failure-resistant infra. Companies could set the same thing up with an in-house team, but it’s pretty great to be able to click a button and start running workloads at tens or hundreds of thousands of RPS without needing to figure out the internals.
Can I understand it as a performant celery with a UI?
Not the same thing, because celery and the like are sdk-level abstractions that need you to plug in your own queue (usually Redis, Kafka) and all other components. The Temporal server deployment includes the full control plane, queue, persistent database, UI and everything else. So you only need to manage your worker boxes.
A Rust equivalent to Celery would be something like Apalis [0]. Where every job is just an async function, similar to a Celery task.
[0]: https://github.com/apalis-dev/apalis
With better ergonomics around handling failures.
Durable execution comes with overhead that you'll need to determine whether or not fits your use case. If you're looking for raw speed then durable workflows are going to be a steep trade off. Most workflows should be durable by default, though, so it is more the rule than the exception.
Say you've got a process that spans a bunch of services and touches the real world. Some ecommerce check out for example.
You need to reserve some inventory, charge a card, eventually email a customer and steps can go wrong. So you have queues, and retries and ways to back things out, undo changes.
To my understanding, Temporal's idea is to factor that part out, the queues and retries, and offsetting actions, so you write the logic and not the workflow orchestration.
I think it's useful for implementing Sagas https://temporal.io/blog/saga-pattern-made-easy
Basically, a multi-step event handling system, where the data could be spread across multiple databases/systems, so there's no way to rollback a transaction atomically across all the databases. Instead, you explicitly codify "compensations" to undo your previous commits so that you eventually end up in a consistent state.
Temporal is the orchestrator/framework/library to implement the above in an easier way.
Does it actually work?
In a past job, they tried to implement a similar thing on much lower scale with bidirectional database migrations.
Fortunately, they were mostly ran in one direction.
IME, it works, but at the cost of a pretty large amount of overhead, both in performance and (I think more importantly) cognitive.
Honestly I never did come to a satisfying conclusion on whether I thought it was worth it. The teams I worked on that used it found it neither simple nor easy to use, and I was never sure whether we were really reaping the benefits of correctness in the face of failure at the scale we were running. We eventually migrated everything off of it, and everyone was happier, but perhaps (probably) we had more lurking bugs in distributed failure cases. But to my knowledge we never tracked down an incident to the kind of problem that temporal solves.
I guess I'd say that I like durable execution (or at least temporal specifically, it's the only system like this that I've used) in theory, but not really in practice.
The fintech (now bank) that I worked in couple of years ago utilized this pattern pretty effectively.
The overhead of doing something in this way is quite large, but, as this handled literal money, it was definitely worth it.
Yeah, I’ve seen it working. It does work well to implement a multi-system transactional workflow broken down into retryable steps. So, eg, if you are operating a SaaS and need a workflow for new customer signup to wait for multiple steps that might last for hours or days like: validate credit card info, wait for email confirmation, add entries to customer database, set up workspaces in downstream systems, spin up cloud resources, initialize systems, notify customer, start billing cycle, etc. and if any step fails, you might want to retry or send alarms or internal notifications, or roll back other steps, or kick off other workflows. Then you can define all of that, in code. Each step can be different runtimes run on different worker systems, etc, all coordinated through a central database.
You can scale the workflows up and down to as complex or simple as you want for whatever your business is. The example above is one I’ve seen, but it works on a smaller scale as well. But you have to write the implementation code in very specific ways to get the benefits, and the overhead ends up being very difficult to plan and reason about, and a lot of business logic actually gets hidden amongst the weeds of the tool’s overhead.
In concrete terms if your app has functions that do very little work but run for hours or days at a time blocking on external resources, and it is acceptable to add 100+ms latency + a serialization boundary to every function call, it is acceptable to take on a bunch of other tooling complexity, and you are willing to sacrifice verifiability of the code, then it might be a fit. In those situations the structure of it (or DBOS or similar) can help standardize that part of your app. Unlike a regular state machine based approach it's easier to represent branching logic and so forth in imperative code. I think its popularity is like the Mongo NoSQL fad, it looks convenient up front but in practice is very painful in most situations. Having used it a fair amount I would recommend starting with actors and state machines, especially in this age of robot code where it's easier to apply heavier approaches to testing in verification.
Asking what temporal is? The founders (Maxim Fateev and Samar Abbas) originally made Amazon Simple Workflow Service (SWF), Azure Durable Task Framework (DTF), and Uber Cadence. Temporal is the latest in the long line of workflow systems they've built. It's a task engine with state, recovery and highly scalable. It's cool stuff, and it simplifies many business workflows when it comes to recovery and scaling. There are many similar systems on the market today that mimic durable functions but Temporal is arguably the best.
When you write traditional distributed systems/cloud native code you have to handle all the failures and retries somewhere. Anyone who's run an Ansible playbook or similar and had a failure halfway through leave the state of the systems in a weird half-state is familiar. Or dealt with spot preemptions or nodes failing or getting unlucky with OOM killer or hardware failures or a myriad of other failure modes.
In Temporal, you use their SDK to mark which code is either:
- Deterministic without external dependencies on network, disk, clock, etc.
- Non-deterministic (e.g. accesses a filesystem, dependent on clock time, talks over the network)
You can write the code without handling flakiness or retries and the Temporal control plane handles all the progress tracking and retries for you. Progress is tracked at the individual line of code for deterministic code, or for non-deterministic code, tracked at function boundaries defined by the programmer. You buy into more complexity upfront, but it makes the application code way simpler and easier to manage overall.
They do a lot of other cool stuff on top of all this, and their Temporal Worker Controller architecture is particularly well suited to running massive scale processing/AI workloads on Kubernetes (handles a lot of stuff like autoscaling without interrupting work, rainbow version rollout, etc.)
temporal makes you split up your async tasks explicitly into a message (a request to fulfill a task, thrown up to a temporal server), and a task handler (pulling a tasks-request from a queue, from the temporal server), rather than both wrapped in a vanilla request/response cycle.
temporal centralizes all the error handling, retry handling, ... some web pages to manage failed, pending tasks.
it's been good for us, but a real step function in complexity of the app.
This is a rough explanation, but generally it does a couple of things that are helpful.
Functionally, it's a "workflow" runner (ex - you can mostly treat it like a queue, where you've got workers that are picking up work to do).
But it wraps a couple of pretty handy features on top like:
- It preserves most arguments to actions, and it makes system details deterministic for retries (ex you can re-run a workflow at a later time, and temporal will make sure the code sees details like date and time as though it were the original run, and will yell at you if you try to write code that won't be deterministic on retries)
- It supports very long waits easily. (ex - very easy to have a workflow do a couple things, wait a week, then do some more things).
- It has decent profiling and UI tools
- It can "restart" a failed workflow deterministically from the step at which it failed (using details from the original point)
---
Basically - it's a background worker service that's put a lot of time and thought into ways to handle failures better.
It absolutely still has some considerable pain points though, and I find it difficult to use for larger tasks (ex - their message gRPC size limit of 4mb is a b*&^% to work around, since it often breaks a lot of the utility they provide, and the history cap at 50mb is also really painful in certain situations.)
Really - I think it was just the right tool at the right time to make calling LLMs with long waits relatively easy and somewhat foolproof.
Another cool thing is it handles version rollouts. Say a customer started some kind of business process on v1.1 of your code, and then you deploy v1.2. You can configure whether that customer should continue that process on v1.1 - even if it's something that takes a long time in the real world - or whether they should be upgraded to 1.2. And it's not just one version but you can do this with an entire rainbow of versions across your business (think A/B testing, custom workflows for different use cases, lots of dev and staging environments, etc.)
Thank you for all the explanations. I think I have better understanding now. Another question, at what scale (in terms of number of services, and maybe throughput? what other dimensions?) should we start considering using temporal?
I think scale is less important than other considerations. For me the biggest motivator is when the use case prefers doing something exactly-once, the downside risk of failure is high, and robust failure handling is moderately complex. The canonical example I use is healthcare communications; others use payment/fulfillment.
Also having a unified control plane is handy even at a pretty small scale if your alternative is going full “cloud native” on hyperscaler microservices. The ability to see what’s happening when and where across a single workflow run is a dream compared to all the traditional logging approaches I’ve seen.
"Why is it such a big deal?"
It's used by OpenAI.
> So... like exception handling?
Yes...with eventual consistency.
If your process OOMs, if the machine restarts, etc.
Plus some other distributed execution advantages.
Absolutely love temporal, but pretty shocked to see they have a $12.55B valuation.... feels nuts?
We're using temporal as the foundation for agents running on our platform doing accounting work for clients, it's proven extremely effective and I love how durable workflows are within temporal.
+100 on the technology, but realizing they are also VC funded makes me a little more cautious when it comes to vendor lock in.
> Our annualized revenue run rate is up more than 200% year over year, and net dollar retention's stayed above 200% since February. In August alone, the platform processed 1.9 trillion billable actions, up more than 350% year over year, while open source installs passed 43 million, up 134% since December 2025. We're now working with more than 4,300 paying customers, up 139% year over year, including OpenAI, Snap, NVIDIA, and JPMorgan Chase.
Congrats to Temporal! They'd just previously raised in February, https://temporal.io/blog/temporal-raises-usd300m-series-d-at...
Any absolute rev numbers?
in the age of agents, surely durable execution is a must.
but the money being raised - what is it for ? go to market ? sponsorship & I like that temporal sponsored Crystal Palace.
we've so many good durable execution engines.
this is the type of VC pollution that will cause companies to end up being acquired by an Italian silverware company (bending spoons).
I’m in an interview loop with them. Hopefully that money is for building my wealth.
> but the money being raised - what is it for ?
Buying DRAM?
Temporal doesn't run your AI compute for you, you bring your own hardware on prem or in your cloud account or whereever. Their SaaS is a control plane to coordinate and orchestrate the workers.
Why not ask the AI to build the control pane for you?
Because the hard part of running it is making it highly available despite the inherent fallibility of distributed computing, which is an infrastructure problem, not an AI coding problem.
Temporal is fully open source, you can run the entire thing on your laptop or your own server. People pay for the SaaS anyway, because dealing with the distributed computing problems is hard.
(There are some other projects inspired by Temporal as well, but if you want to run something in-house, you're probably funding a minimum of 2-3 engineers to handle on-call, and for that price the SaaS is competitive).
That’s 1/3 what IBM paid for Red Hat, simply insane.
Can someone tell me why people prefer temporal over something like https://restate.dev?
Hi! I work for Restate
A few key differences. Restate has a more flexible programming model. You don't write workflows with activitities, but just durable processes/handlers. Durable steps execute inline and get persisted over an open streaming connection in Restate (low latency, lower overhead per durable step, sharing resources like sandboxes) instead of working with a pull-model where each activity executes remotely on a worker. Restate has a lean deployment model with a single binary that can be deployed multiple times to have a highly-available cluster (potentially spread across multiple regions). It is used for large-scale production clusters, and so lightweight here does not mean less reliable than Temporal.
You can do the same things with Temporal like sleep for months etc. You can learn more here: https://restate.dev/vs/temporal
Disclaimer: I'm a co-founder of Temporal.
Temporal has 3 types of activities:
* local: executed in the same process as the orchestrator code. Many local activities can be executed locally before their results are sent to a backend server in a single RPC call.
* task queue based: executed by a pool of worker processes that poll from the queue. This is the most flexible model as it supports flow control, priorities, fair queueing out of the box.
* eager dispatch: task queue based but executed locally if possible as a performance optimization.
Temporal also supports stand alone activities that are invoked without a workflow and dispatched through a task queue.
Restate only supports local activities (using Temporal terminology).
I wouldn't call it a "more flexible programming model".
Restate made several decisions I consider questionable for the system's availability and stability, like pushing work to handlers instead of dispatching it through a queue. Any design decision has tradeoffs. It would be nice if you mentioned these trade-offs in your posts instead of making claims that sound like pure marketing.
Sorry, but this is incorrect (Restate founder here)
(1) You can model the equivalent of local activities and activities that run on other workers in Restate.
A local activity is a step in the workflow function. An activity supposed to run on a different worker is a function called by the workflow function. Since these calls are just Restate events, exactly-one, suspendable, this gives you a full-fledged workflow/remote-activity pattern. Including concurrency, separate retry policies, etc.
(2) Restate steps commit individually, unlike local activities.
Imagine a two-step workflow, where you want one step durable before starting the second. Account withdrawal before deposit. Restate steps allow you to do that, each step is durable committed before the next step runs.
Per Temporal's own docs, Temporal Local Activity results become durable only when the enclosing Workflow Task completes. That's different than Restate, which can durably commit every individual ctx.run before proceeding to the next step.
Making actual durable commits fast, so you can have sequences of fast durable steps building on each other is super valuable. If an agent can commit the guardrail evaluation in low milliseconds before it starts the tool call, that's great, do it. If committing this involves dispatching another workflow or activity task, the consideration is harder.
When we see someone migrate a Temporal workflow, they often end up using many more durable steps in Restate than they used activities before.
(3) Why do we consider it flexible?
(a) Virtual Objects: Keep state around across the workflow, without doing tricks like "keep the workflow running, signal only, continue_as_new" after a while. Virtual Objects are a natural way to model concurrent stateful entities.
(b) non-workflow communication patterns: We have seen users build lot's of different patterns. It can get as crazy as graphs of functions/objects sending each other durable messages. All end-to-end idempotent (or exactly once, for Virtual Object state). That is outside the hierarchical workflow/subworkflow/activity abstraction.
(4) availability and stability
I don't know where the perception with stability comes from, Restate pushes some pretty high volumes for customers, like 100k+ actions/sec.
The push model in Restate is internally dispatched through queues as well. The application just don't see it as task queues. Limits are implemented through virtual-queues in Restate 1.7.
-----
Of course the systems make different trade-offs. The Restate design (vqueues, push model) is took us longer to build than a task queue model would have, because it puts more work onto the dispatcher that is otherwise handled just implicitly by the worker pools.
But once it is there, it is sooo nice, in how easy it integrates into infra, and how it can handle flow-control with high hierarchical limits in ways I genuinely haven't seen in any other system achieve (see https://restate.dev/blog/announcing-restate-1-7 )
Might not be par for the course for HN, but gotta drop a link with a light joke, with the background of the money grubbing guy (Temporal founder here) sucking up venture capital like vacuum cleaner who tries to argue he’s intellectually superior in a brag thread about his Company over a competitor (with significant OSS accomplishments) who is attempting to make the world a better place with a freely available primitive that isn’t just available to dev teams at mega teams at Netflix and OpenAI etc.
Stay humble / nice ego dude.
Necessary reference: https://share.google/7uReiRkd6mY3RcCQQ
Hmmm, that feels not very nice, tbh. I have big respect for what Maxim and the team built, and both systems are essentially open and free (publish code and are free to use).
Do you realize that Temporal is fully open source under the MIT License, while the competitor is under BSL?
I certainly don't think I'm superior to them in any way and have great respect for the very capable team they are. We know each other personally. I even presented at the Flink conference while at Uber.
My message is that I'd prefer a more technical discussion of the merits of our products rather than simplified marketing attacks.
How does that compare to Inngest? As I understand it it also executes inline and has a streaming connection to the inngest server. We ended up going with them over temporal because it was so much simpler operationally, but restate seems even lighter. I can appreciate how it's hard to tackle the enterprise market, but the temporal solution feels so bloated I really hope the industry can standardize on some simpler patterns
How do “stream over an open connection” and things like “sleep for months” play together?
Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.
The way it works is that Restate supports suspending workflows that sleep for months and later (once the sleep finishes) resumes them at exactly this point. Technically, this is the same process as resuming a crashed workflow.
While the workflow is actively doing work (like calling other services, accessing state or interacting with external services, for example) the server is connected to the workflow deployment via a low-latency bidirectional streaming connection to receive and acknowledge progress that the workflow makes. That way the workflow can finish as fast as possible.
A nice side effect of this model is that you can co-locate your workflow with expensive resources, such as a sandbox, which should be used by all durable actions that the workflow executes. The reason this works is because Restate can inline durable steps (what would be modeled in Temporal as activities, I believe).
If a handler starts a sleep/human approval/RPC call, or so, then this timer/promise is persisted in Restate's journal. Restate does the waiting. The handler process itself can suspend (e.g. on a serverless function), and the bidirectional connection is closed. Once the timer fires/approval comes in, Restate re-invokes the service with the journal of previously completed steps, and the service can replay to the exact point in the code where it suspended and continue from there. Restate is like a DB for journals, so you can sleep for as long as needed, also months.
So you have fast persistence of events while a handler can make progress, and suspensions while waiting.
I guess the confusion is that it doesn't have to be one single persistent stream.
While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (typical durable execution style).
That gives you the best of both worlds: same long-running workflows with long sleets and suspensions, but also ability to add steps with few ms overhead only.
btw does restate run on Cloudflare workers ?
Yes it does: https://docs.restate.dev/services/deploy/cloudflare-workers
The responses to this thread seem to be from people who are familiar with Temporal but haven't ever actually used Restate. They're both durable execution platforms, with differences mostly around how abstractions are organized and how orchestration of work happens (Temporal has you setup worker pools that pull from a queue while Restate pushes to service handlers). If some of your infra runs on serverless providers, Restate will often be a more natural fit.
Sure, Temporal is more mature and battle-tested, but Restate is quite nice and I honestly prefer it in most cases.
EDIT:
I started drafting this reply before seeing someone from the Restate team chimed in.
Those two don't really compare. Temporal has been around 3 years longer and is a much more heavyweight system. Temporal can support workflows that sleep for months at a time and still reliably finish.
I'm sure there is a place for restate.dev, but it isn't in the same place as Temporal.
Disclaimer: I am a co-founder of Restate.
Like Temporal, Restate supports workflows that sleep for months at a time and let's them reliably finish.
It actually does many more useful things. For example, you can have services that remember state across invocations and there is no need for continue-as-new.
Since Restate allows inlining durable steps into your workflow, it is very easy to co-locate your workflows with expensive resources such as sandboxes or other per-node resources. And the nice thing is that each durable step is really cheap and adds only minimal overhead.
AI workflows are a convenient fit for temporal, their platform is great for much more than just those. It’s an elegant and easy to use solution for a lot of workflow needs.
That's fair, but they are also a great fit for Restate. For example, Replit migrated their whole coding agent from Temporal over to Restate, a pretty big setup.
Restate is directly inspired by Temporal.
Disclaimer: I am a co-founder of Restate and might be biased.
Restate's spiritual father is Stateful Functions (https://nightlies.apache.org/flink/flink-statefun-docs-maste...) a library for event driven applications built on top of Apache Flink. If you want to learn more about why we started building Restate, I recommend this excellent blog post https://restate.dev/blog/why-we-built-restate.
I understand that Restate and Temporal look similar from a superficial perspective but Restate is not only a durable execution engine but a durable runtime that also provides consistent state and reliable communication. These are the building blocks to build reliable agents and applications w/o having to fit them into a workflow-activity like model. If you want to learn more about how Temporal differs from Restate, check out https://restate.dev/vs/temporal.
Love to work with Temporal workflows
Have been using Temporal since 2025, congrats!
Why isn't there more love for dbos.dev ?
I think it’s nice that it’s just an SDK and a Postgres database, but they don’t have SDKs for the languages we use at work.
Hey, out of curiosity: which languages are those?
Mostly C#, as I see your Rust SDK is under development.
Unfortunately it appears someone vibe-coded a port of the Java SDK for .NET and namesquatted the `Dbos.Transact` package on NuGet [1], making it look like an official SDK. It's also not a very good port, mirroring the Java implementation instead of using idiomatic C#.
If you ever plan on releasing a .NET library, I suggest opening up a dispute resolution [2] with the owner (it really is just an email to the guy, CCing NuGet support) and reserving the `Dbos` prefix [3].
[1]: https://www.nuget.org/packages/Dbos.Transact/0.0.0-alpha.0.4... [2]: https://learn.microsoft.com/en-us/nuget/nuget-org/policies/d... [3]: https://learn.microsoft.com/en-us/nuget/nuget-org/id-prefix-...
Porting and rewrites between languages is a task frontier models excel at
No. A huge selling point of these code-first workflow engines is that they make writing durable workflows a lot like writing non-durable code, to the maximum extent that the language allows, such that the workflow orchestration disappears.
That is, they require good taste and opinionated API design first, porting skills second. The SDK for each language ends up being substantially different.
Frontier models are not very good at this yet. I've tried. Ultimately I couldn't justify the effort when there are other workflow engines out there.
[dead]