Сначала нужно учесть, что постгря в отличие от мускуля не на потоках, а на процессах. На каждое соединение спавнится отдельный подпроцесс, который очень жирный и очень дорогой по startup time. Поэтому для постгри idle соединения беда бедовая и нужен мультиплексор. Если у тебя кластер из узлов бэка, в конфиге каждого узла нужно ограничить соединения в БД пуле до доли от общего количества, иначе какой-то узел "перетянет одеяло на себя". А учитывая что щас любой ынтерпрайз - это контейнеры и кубер (и его дистрибутивы, типа OpenShift), то их модель работы плохо ложится на клиентский пулинг (кубер в любой момент может потушить контейнеры в облаке, исходя из текущей нагрузки), то верхние границы оставшихся в живых клиентских пулов перестают соответствовать текущему конфигу max_connections сервера PG (а max_connections никогда не будет большим, иначе база сожрет весь хип). Поэтому де-факто уже давно стандартный рецепт воткнуть pgBouncer как внешний прокси и не придумывать себе задачи на ровном месте. Работает - работает. К производительности решения вопросы есть? Нет. Если же у вас монолит или кластер какой-нибудь на какой-нибудь технологии из прошлого, по типу JavaEE application server, то действительно внешний пулер не сдался, всё можно засунуть в клиентский. Справедливости ради, если какой-нибудь бизнес заказал вам разработку сервиса в интернетах (типа магаза), то у него должны ОЧЕНЬ хорошо идти дела, чтобы ему начало не хватать монолита PHP/Python + MySQL. Я в начале своего айтишного пути работал в одной крупной российской торговой компании с федеральным охватом. Они сидели на Битриксе 15(!) лет и начали переползать на Golang и VK-шные и Яндексовские облака, только когда открыли больше 150 магазинов по стране, а количество сотрудников перевалило за 3000. Сделаю еще раз акцент на том, что даже такое днище как Битрикс до вышеобозначенных цифр держал нагрузку.