[throwaway313373]

Why is it "shocking"?

It's just an architectural decision to spawn a process per connection that Postgres made long time ago.

It's a tradeoff like most decisions.

Back in the days MySQL had huge issues with scaling to multi-core systems (maybe they fixed it now, I haven't used MySQL for a long time) while Postgres never had this problem.

When designing an application around Postgres you just have to take into account that:

1. opening a new connection is rather expensive, so you should have a connection pool

2. opening too many connections is problematic, so you should keep the size of your pool rather small and return connections back into the pool ASAP

That's it.

It's not that hard in practice.

[brianaker]

MySQL never had a problem with scaling to multi-core systems; Linux on the other hand did have a problem and its problems became everyone's problems. In the early 2000's the answer to multi-core Linux issues was to buy a system running one of the commercial UNIX. By 2006 or so this became a non-issue for Linux ( for the most part ).

Postgres uses an old design model which predates threads; I have no idea if they have made any progress in updating their design. In the past I have heard the core devs talk about how difficult it would be to do this.

Oracle Database moved to a hybrid process/thread model at some point, this is the superior solution ( I have no idea if it was done well or not, but from standpoint of how to achieve better leverage of CPU vs IO, this is the way ).

If the PG devs had enough time/money, I am sure they would move towards a hybrid model where the focus would be on processor affinity with IO being all tied to events.

[xxs]

Years back (around 10) mysql did have multiple instances of false sharing[0].

Unrelated to mysql - I do consider using redis in any capacity a blunder (it's likely ok for nodejs users, I suppose)

[0]: http://dimitrik.free.fr/MySQL_Connect_2013/MySQL_Perf-Connec...