Thanks! Convex looks neat, and you’re right, there is a lot going on at the data and data/frontend layer. Our approach is to provide a generic compute layer with the session-lived backend model, so you can do more than just store data with it.

So, I presume, instead of a shared multi-tenant architecture convex), Spawner prefers per-user business-logic container + a per-user database container (+ any other module)? If so, once a user-session is adjudged to have been over, does Spawner snapshot them all to restore it whenever a session is to be resumed?

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.