zlacker

>>davidg+(OP)
Can’t believe they needed this investigation to realize they need a connection pooler. It’s a fundamental component of every large-scale Postgres deployment, especially for serverless environments.

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

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

>>IsTom+wL2
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.