Про возможность изменять пока не скажу, т.к. сам сервер с базой я ещё не поднимал.
Другие параметры оставлять стандартными? В облаке был изменён лишь флаг max_connections с 600 до 4000

Другой момент, который хотелось бы озвучить.
Как упоминали ранее, лучше иметь в команде DBA, который будет в этом разбираться. Но на данный момент это не представляется возможным. С Postgres мы работаем в первый раз, и тонкостей, естественно не знаем, и переходить на другую базу, скорее всего, не будем в виду того, что придётся так или иначе переписывать воркеры и другие сервисы, и дополнительно это не отменяет того факта, что в другой базе не будет аналогичных проблем.

Возвращаясь к сути вопроса: увеличение RAM и количество соединений. В данный момент необходимо запроцессить исторические данные. Записей около 100 млн. Конечно же это нужно сделать в кратчайшие сроки, чтобы можно было выполнять дальнейшую работу по анализу полученных данных и сделать и итоге MVP, которое покажет суть работы.
У нас имеются воркеры, которые могут обрабатывать в сумме до 5,000 записей (и больше, в зависимости от поднятых машин) в секунду. Операции которые выполняют воркеры — самые простые, без кучи связей (4 таблицы всего, в сумме 21 колонок):
1. Проверка записи на существование в базе
2. Добавление записи в базу
Такие процессы выполняются без батчей. Какой pool_size указан в воркере, столько операций insert/exists выполняется одновременно.
Отсюда и вытекает необходимость в большом количество подключений к базе. На данный момент переписывать логику работы воркеров трудозатратно и, по сути, бессмысленно, т.к. нужно проделать эту операцию (прогон исторических данных) всего один раз. С дальнейшими ежедневными обновлениями справится и 1-2 воркера на каждый сервис, которые, естественно, базу в текущем положении не положат.
И опять возвращаясь к вопросу: возможно ли в данный момент настроить Postgres так, чтобы он не падал от 3-4 тысяч активных подключений к нему? Конфигурация база может быть любой: CPU, RAM, Storage.
Из возможных вариантов пробовал PGTune. Но поскольку я это пробовал всё ещё на Google Cloud SQL, то некоторые параметры настроить было невозможно. Возвращаясь к использованию Bitnami (будет собственный сервер с возможностью настройки postgres.conf) — поможет ли PGTune в данном случае? Указание RAM, CPU, количества подключений — и подтверждение изменения предложенных им [PGTune] конфигов. Либо нужно что-то другое?

P.S. Прикрепляю график RAM за весь день. Можете сравнить его с тем, что было в предыдущий раз. Стало хуже, хоть и изменилась только база. В моменты, когда графики идут на спад — база недоступна — воркеры висят. В прошлый раз спад был практически моментальный, из-за чего воркеры начинали работать в течение нескольких минут.

Видимо, пула нет

Ну, если использование этого не является использованием пулов — то явно что-то не то :)
https://docs.sqlalchemy.org/en/14/core/pooling.html

> Прикрепляю график RAM за весь день.

Это график, конкретно, чего?

А какое значение там указываете?

График RAM, когда целый день были запущены ~50 машин [воркеров], которые в итоге создали ~3500 подключений к базе

Да, в том и дело. Эти ~100 млн. строк нужно обработать один раз целой пачкой, дальше такого не будет

Тогда откуда может взяться такое дикое число коннектов? Сколько у вас инстансов приложения запущено?

Один машина [воркер] создаёт 8*8 тредов, 1 тред = 1 активное соединение
40-50 машин одного типа,  5-10 другого

Я повторю вопрос про количество одновременных соединений.
Так почему Вы считаете, что стоит использовать большее их количество, чем есть CPU cores?

зачем столько-то?! быстрее от этого не будет ни разу

Один машина [воркер] создаёт 8*8 тредов, 1 тред = 1 активное соединение
40-50 машин одного типа,  5-10 другого

Питонячьи треды-то?