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.
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.
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.
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.
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.)
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?
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.)
> 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.
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.
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
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.
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.
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.
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
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.
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.
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.
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 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.
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.
Congrats to Temporal! They'd just previously raised in February, https://temporal.io/blog/temporal-raises-usd300m-series-d-at...
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.
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
Naively without digging into the code I would look at a “streaming over an open connection” as likely to strictly more brittle.
I'm sure there is a place for restate.dev, but it isn't in the same place as Temporal.
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).
Buying DRAM?