Как правильно тюнить конфиги БД, распределять ресурсы?

Макс храню в InnoDB, чем собрать статистику ?

для mysql есть mysqltuner . -он Вам напишет сколько в каком движке. Заодно и немало интересного про использование кэша, read\write rate напишет, кое-какие советы по оптимизации конфига выдаст.
только не кидайтесь сразу в слепую выполнять эти рекомендации
в постгресе - тут придется погуглить. объем базы вроде как через \l можно посмотреть.

тема оптимизации БД очень нескучная тема.
я бы очень посоветовал после понимания объемов данных посмотреть насколько Вы много пишите или читаете ( ожидаемо на запись кэш особо не влияет), потом оценить cache hit rate - это насколько хорошо чтение попадает в кэш. Если данных мало, кэш большой а хитрэйт низкий - точно нелишним будет порыться в запросах, бываю ТАКИЕ перлы... у меня был пример, когда из таблицы в 17М строк каждые пару секунд читали все. Или другой пример, когда из таблички в 25-30М строк вытаскивали строчек 500-1000, но по полю без индекса.

Макс, mysqltuner не работает с MySQL 8 уже проверял (

тогда sql-ными скриптами.

Макс, существует ли мониторинг нагрузки, чтобы посмотреть по нагрузке на mysql и postgresql и распределить ресурсы по приоритету нагрузки ?

автоматически - мне таковые не известны. Мониторинг нагрузки да хоть тот-же Заббикс.

Макс, размер БД также стоит учесть при конфиге ?
К примеру сумарный размер БД на Postgresql - 12Гб, MySQL - 260Гб
Больше трафика приходит на Postresql, есть ли формула по которой можно все просчитать ?

Chvalov, формула врядли, скорее уж здравый смысл.
вот смотрите, в постгре данных всего 12Гигов. значит вот прямо сейчас отдавать под кэш в него более этих 12 гигов особого смысла нет, постгре они не помогут. т.е. уже память пополам делить смысла нет. Однако он, по Вашим словам, основной источник данных.
В мускуле данных изрядно. на секундочку в 20 раз больше. однако всего памяти 32, БД мускуля хоть упрись в память не загрузишь.
значит будем искать компромис.
Я бы начал с того, что отдал бы 12 гигов под shared_buffer Postgres-а, effective_cache_size - еще 4Г. из оставшихся 16 12г под innodb_buffer_pool, гиг по мелочи между остальными буферами мускуля.
дальше подождал бы день-два и посмотрел на кеш-хит-рэйт