If you have lot of client sources (say in each micro service) different languages and frameworks connecting to same server ( perhaps different db/schema ). It

If you have lot of client sources (say in each micro service) different languages and frameworks connecting to same server ( perhaps different db/schema ). It is easier then to manage it in one place . Also dynamic scaling of server pools etc you need change the pooler config instead of every application. And postgres connection management(open/close) is expensive, if you can handle it outside the the db infra it can be beneficial ( only some client libs will pool their connections and others won't). Even with client pooling support in the library, each container/forked runner will have its own connection, and that can be quickly few hundreds. Finally AFAIK most libraries don't handle master failover or server restart without crashing the connection, pooler will usually keep the upstream open for some time.