[jstrong]

can't believe postgres still uses a process-per-connection model that leads to endless problems like this one.

[IsTom]

You can't process significantly many more queries than you've got CPU cores at the same time anyway.

[namibj]

Much of the time in a transaction can reasonably be non-db-cpu time, be it io wait or be it client CPU processing between queries. Note I'm not talking about transactions that run >10 seconds, just ones with the queries themselves technically quite cheap. At 10% db-CPU-usage, you get a 1 second transaction from just 100ms of CPU.

[jstrong]

redis is single-threaded but handles lots of connections (i.e. > 500) with much better performance vs. postgres. there's zero chance someone building postgres in 2025 would do one process per connection, I don't think there's any argument that it's a good design for performance. it's just a long-ago design choice that would be difficult to change now.

[hu3]

I disagree. If that was the case, pgBouncer wouldn't need to exist.

The problem of resource usage for many connections is real.