For a many of those values, the answer would be "as much as you like", but with awareness for tradeoffs. You can store a lot of data in Restate (workflow event

For a many of those values, the answer would be "as much as you like", but with awareness for tradeoffs. You can store a lot of data in Restate (workflow events, steps). Logged events move quickly to an embedded RocksDB, which is very scalable per node. The architecture is partitioned, and while we have not finished all the multi-node features yet, everything internally is build in a partitioned scalable manner. So it is less a question of what the system can do, maybe more what you want: - if you keep tens of thousands of journal entries, replays might take a bit of time. (Side note, you also don't need that, Restate's support for explicit state gives you an intuitive alternative to the "forever running infinite journal" workflow pattern some other systems promote.) - Execution duration for a workflow is not limited by default. More of a question of how long do you want to keep instances older versions of the business logic around? - History retention (we do this only for tasks of the "workflow" type right now) as much as you are willing to invest into for storage. RocksDB is decent at letting old data flow down the LSM tree and not get in the way. Coming up with the best possible defaults would be something we'd appreciate some feedback on, so would love to chat more on Discord: https://discord.gg/skW3AZ6uGd https://discord.gg/skW3AZ6uGd The only one where I think we need (and have) a hard limit is the message size, because this can adversely affect system stability, if you have many handlers with very large messages active. This would eventually need a feature like out-of-band transport for large messages (e.g., through S3).