[TZubiri]

Some see a 30 year old system and think "outdated", I see a 30 year old system and think "time tested."

Clearly a process per connection is more stable and that's what I'm using.

It's unclear what problem such optimizations are solving anyway, with the old way you could only support a million concurrent users with a single server? Are we missing out on supporting ten million concurrent users with 2 servers instead of 10? Ostensibly reducing the minimum db hardware opex for a 10B$ company from 10k$/month to 2k$/month?

[film42]

A million users? Hell, I'd bet 99.999% of live postgres databases in existence serve less than 5 users on average. Even among products that actually make a profit, I bet 99.9% of them serve less than 100 customers a day. We hooligans on hacker news manage the 0.1% of databases, and in my newfound consulting life, I'm hoping to never support one of those again.

[vanviegen]

> Clearly a process per connection is more stable

Even if those processes share most of their memory, and are written in a notoriously memory-unsafe language?

A significant performance improvement can well be the difference between being able to run the entire database on one beefy server, and having to shard. And that has a huge cost in terms of complexity and thus reliability and development time.