Кто масштабируется?

Сервисы

Ну и для отказоустойчивости

А баунсер тут при чем?

в данном случае используется ibm bpms

При том, что если у каждого инстанса сервиса свой внутренний пул коннектов, то не получится контролировать количество подключений к БД. Формула N * M (N  - количество инстансов, а M - количество коннектов в пуле приложения) не работает, потому что N может от нагрузки зависеть

И это справедливо не только для джавы

ну это если scale out? в тяжелом enterprise зачастую N фиксированно.

а вот M - конечно плавает от Initial до Max, с доп настройками аля Keep-Idle.

Насчёт интерпрайза ничего не скажу, я с ним не связан

M - да, плавает

Для этого баунсер и нужен чтоб не контролить эти Мэ и Нэ. Но при росте нагрузки увеличение Нэ может уже не помочь тк весь перфоманс упрется в однопоточный баунсер , который будет в сотку.
Но до поры до времени баунсер хорош но потом он начинает превращатся или в костыли или в Одиссей

да, баунсер упирается в ядро. обходится запуском 2-3 (и более) баунсеров на разных портах с round-robin ротацией между ними.
с версии 1.12 баунсер на линуксе умеет в SO_REUSEPORT — несколько процессов слушают один порт и ядро балансирует подключения автоматически

ну есть ещё penalty в latency от баунсера. Да и SPOF дополнительный. Теперь либо баунсер упадёт, либо постгрес. Даже не сам софт, а инфра

эм… смысл баунсера в том, что не надо открывать сессии к базе. в этом месте мы имеем ускорение на 2 порядка. в результате latency penalty ставновиться на уровне погрешности.

так сессия открывается только при старте приложения. Дальше сессия живёт. а вот лишние 2 пакета на каждый запрос - это не погрешность

- если это так, то это плохо: рекомендуется ротировать сессии ( сбрасывать локальный кэш, какая-никакая защита от утечек памяти, новые настройки подцепить).
- не очень понимаю о каких 2 пакетах вы говорите? у приложения контрагент по прежнему один, баунсер типино ставится рядом с базой и ходит через сокет
- если 2 сетевых пакета ощутимо, то возможно следует на сеть посмотреть?

ладно, понятно что не поняли))))

я понимаю что вы говорите.
но мой опыт говорит, что для жавы баунсер очень даже помогает.
возможно он нивелирует неумение готовить пулы на стороне приложения, но это частный случай (только 25% я бы оценил как подходящие сюда).
следует заметить, что он позволяет прозрачно направить трафик на другую базу и/или поставить трафик на паузу — крайне полезно для обслуживания баз

так это ж забавно - закрывать неумение в одном месте инструментом в другом. И потом массово публично обсуждать отрицательные стороны инструмента в другом месте, аля pgbouncer плох по tps или pgbouncer плох по секьюрити, забывая о неумении в исходном месте. Извините, прошу без обид, но изобретать себе геморрой на будущее не обязательно.  java хорошо умеет делать connection pool-ы, и postgresql не сильно хуже oracle умеет поднимать новые коннекты при создании сессии.