You could run a database for each user inside Spawner, and there are use cases for that, like being able to run queries against arbitrary parquet files or mater

You could run a database for each user inside Spawner, and there are use cases for that, like being able to run queries against arbitrary parquet files or materializing a sample of a larger dataset for fast queries. But in general if you just want to store program state, you would probably want to use Spawner for the compute and a multi-tenant database for persistence. We expect that Spawner will usually be part of a larger system that involves some multi-tenant components. Spawner doesn’t manage any persistence automatically, it’s up to the application. For some use cases, sessions are meant to be ephemeral (like a whiteboard session, or read-only data exploration), so there’s no state to persist at the end. For apps where there is state to persist, one option is desktop-style auto-save. By that I mean that the ground truth document state is in-memory, but every change to it triggers an asynchronous write to a persistent store. This is preferable to one-shot persistence at the end of the session for the same reason as it is on desktop apps: if there’s a power outage or hardware failure, you only lose a few seconds of work.