[ConnorLeet]

Do you have any resources to point me towards that elaborate on the benefits of a process-per-tenant/user for performance?

I work on a data-intensive app that fits the use-case you describe but I'm confused about the benefits for performance. (can certainly see how the code would end up nice/simpler) Is this mostly applicable to certain stacks?

[paulgb]

> Do you have any resources to point me towards that elaborate on the benefits of a process-per-tenant/user for performance?

Not yet, but we're working on some demos of things that are easier with session-lived backends. One way to think about it is that it's good for repeated queries against the same subset of data -- if you have a dataset of petabytes and your typical use case has users (through filters or queries) repeatedly accessing a sample of ~gigabytes of that data throughout a use session, you could use a session-lived backend to materialize that subset of data in-memory and quickly serve queries off of it without hitting the global index.

Another case where it comes up is when you need to do some stateful computation after loading the data, for example, if you need to generate a graph or embedding layout of some data and refine the layout when users select/deselect data.