that's the point - my understanding is that he created it as a result of reluctance of core pg team to make progress on these more low level and fundamental problems. I'd be interested to know what core pg people think of it - whether it's just too costly to implement these enhancements in pg, or they think these are just not desirable/correct per se.
Plenty of guys complaining about dating on TikTok too. It’s an absolutely massive platform and there’s videos on just about anything especially interpersonal relationships (coach industry)
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?
> 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.
