3 ms·

Can someone tell me why people prefer temporal over something like https://restate.dev https://restate.dev?

slaughtr 17d ago
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.
- sewen 17d ago
  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.
nosequel 17d ago
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.
- stsffap 17d ago
  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.
bpicolo 17d ago
Restate is directly inspired by Temporal.
- stsffap 17d ago
  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-master/ 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 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 https://restate.dev/vs/temporal.
gvdongen 17d ago
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 https://restate.dev/vs/temporal
- skrtskrt 17d ago
  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.
  - gvdongen 17d ago
    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.
  - stsffap 17d ago
    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).
bilalq 17d ago
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.

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.

sewen 17d ago
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.

nosequel 17d ago

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.

stsffap 17d ago
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.

bpicolo 17d ago

Restate is directly inspired by Temporal.

stsffap 17d ago
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-master/ 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 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 https://restate.dev/vs/temporal.

gvdongen 17d ago

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 https://restate.dev/vs/temporal

skrtskrt 17d ago
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.
- gvdongen 17d ago
  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.
- stsffap 17d ago
  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).

bilalq 17d ago

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.