>>> I'm wondering a bit about that as many frameworks/libraries that use Postgres already implement an internal connection pool.
That's precisely the problem.
The usual misconfigured python/ruby application will throw 16 connections at the database.
The model for these languages is to deploy one process per core, so there will be 8 concurrent processes running. 8 cores * 16 pool = 256 connections total.
Multiply by N parallel servers and that's even more connections.
There are issues with large amount of connections and postgresql, hence people decide to put pgbouncer in front of the database to mitigate.
That's precisely the problem.
The usual misconfigured python/ruby application will throw 16 connections at the database.
The model for these languages is to deploy one process per core, so there will be 8 concurrent processes running. 8 cores * 16 pool = 256 connections total.
Multiply by N parallel servers and that's even more connections.
There are issues with large amount of connections and postgresql, hence people decide to put pgbouncer in front of the database to mitigate.