Hacker News Reader

Go on? Postgresql does process per session / query, and it scales ridiculously well, especially with the hilariously multi-core systems we have today.

Although it doesn't handle unbounded concurrency, there are techniques (like manual locking, or pgbouncer) to deal with this.

View on HN

So Daytona compiles and runs a new binary for each query, not just for each connection, and does all its coordination through files + pipes + shared memory. Query binaries even fork themselves for parallelism(!). My understanding is that the cost of switching between kernel and user space is pretty overwhelming. Maybe STM would help that someday but now you’ve implemented an actual database in the kernel...

PostgreSQL’s process per user model makes way more sense but as you say still has upper limits on concurrency.

Not sure how to read that. Isn't simply 1 process per connection?

Yes. But you can't run more than one query per connection.

One executing query per connection, meaning a connection maintains a serialized query processing model.

Reply on news.ycombinator.com