То, что у вас в конфиге закомментировано - не просто так, а проверка работоспособности СУБД. Иначе оба контейнера стартуют одновременно и Постгрес не успевает подняться. То же самое без внешних скриптов реализуется с помощью depends_on + healthcheck.
Нет никаких "рекомендуемых настроек для docker-compose.yaml". В докер-образ через переменные окружения, разумеется, пробрасывается далеко не каждый параметр, поддерживаемый Постгресом.
Чтобы настроить TLS, вам, как минимум, откуда-то нужно будет взять приватный ключ и сертификат - и подложить его в контейнер. Относительно же конкретных параметров - в большинстве случаев подойдут дефолтные.
Зачем вам поднимать БД из бэкапа ВМ, если у вас есть консистентные дампы на соседнем диске? Если же хочется иметь максимально свежую версию данных - это решается репликацией и/или архивированием WAL.
pgbouncer начал поддерживать prepared statements совсем недавно и в ограниченном объёме. Если есть возможность - лучше от них избавиться.
В целом в вашем случае пулер - то, что нужно. Если приложение не умеет само вовремя отключаться от базы, пусть лучше занимает слоты у pgbouncer.
Принудительно рубить idle коннекты я бы не стал, но в целом это делается вот этим параметром:
client_idle_timeout
Client connections idling longer than this many seconds are closed. This should be larger than the client-side connection lifetime settings, and only used for network problems.
Потому что когда на сервере работает несколько сервисов, им нужно явно указывать, сколько памяти они максимально могут потреблять - и в сумме должно получаться меньше, чем есть на сервере (минус сколько-нибудь под процессы ОС). Для Постгреса и вовсе - первая операция после установки, это редактирование настроек памяти.
Альтернатива ковыряния конфигов - разнесение всего хозяйства по контейнерам с лимитами памяти.
Сколько, по-вашему, при ресторе БД весом 80 ГБ накапливается WAL, больше или меньше значения, указанного вами в max_slot_wal_keep_size? К каким последствиям это может привести и почему?
Правильно настроенному по памяти Постгресу своп не нужен. Единственные возможные грабли связаны будут не с СУБД, а с остальными процессами ОС - нужно предусмотреть для них достаточный объём памяти.