so you are suggesting you close a connection between queries?
Between transactions? Yes, absolutely
In fact, many libraries do it automatically.
For example, SQLAlchemy doc explicitly says [0]:
> After the commit, the Connection object associated with that transaction is closed, causing its underlying DBAPI connection to be released back to the connection pool associated with the Engine to which the Session is bound.
I expect other reasonably sane libs for working with transactional databases do the same.
So, if you are doing pooling correctly, you can only run out of available connections if you want to have a lot of long running transactions.
So, why would you want every of your 50k frontends keep an open transaction simultaneously?
[0] https://docs.sqlalchemy.org/en/20/orm/session_basics.html#co...
Of course, the better design is to write a nonblocking worker that can run async requests on a single connection, and not need a giant pool of blocking workers, but that is a major architecture plan that can't be added late in a project that started as blocking worker pools. MySQL has always fit well with those large blocking worker pools. Postgres less so.
From the perspective of keeping the number of open connections low it doesn't really matter if you close it or return to the pool, because in either case the connection becomes available to other clients.
If you are saying that a connection pool can be shared between processes without pgbouncer, that is news to me.
> Parent comment is talking about one connection per process with 50k processes.
It is actually not clear what parent comment was talking about. I don't know what exactly did they mean by "front ends".