Melkij

innodb - это MVCC.
Чтобы узнать, сколько строк в таблице - нужно узнать, какие версии строк может видеть эта транзакция. Без вычитывания всех подходящий строк ответ не получить. Разумеется, быстро это работать не будет.
Поэтому данные в information_schema - приблизительная оценка всегда.

Уменьшайте объём данных. Например, если вы растёте по шкале времени, то стройте аггрегаты по времени заранее. Например, по дням и часам. Текущий час s/вычитывать count'ом/инкрементить в каком-нибудь редисе или мемкеше вместе с insert'ами/g,, потом пересчитывать и сохранять к другим аггрегатам.

Как разделить таблицу, горячие данные оставить на SSD, холодные - на HDD. Для этого во-первых партицирование для разделения таблицы на две. https://habrahabr.ru/post/273933/ (как обычно, внимание на комменты и pg_partman)
Затем, до миграции данных (или сразу при создании партиций), перенос архивных в другой tablespace www.postgresql.org/docs/current/static/sql-createt... stackoverflow.com/a/11228536 на HDD.
Затем миграция данных на партиции.
Вообще-то, это уже может быть вполне достаточно. 1-2млн строк * 365 дней это не запредельно много. Хотя не указан характер данных.

Прозрачный для приложения перенос таблиц на другую железку - FDW, foreign data wrapper. Чем актуальнее postgresql - тем лучше. Пилится штука весьма активно по части оптимального распределения запроса. Дружит ли уже с партицированием - честно, не в курсе.

Прозрачно отправить запрос на две базы и склеить - элементарно view с union all из локальной таблицы и FDW. Только это неинтересный вариант, зачем для запроса на горячие данные дёргать холодную часть базы?

Вдобавок, можете посмотреть в сторону postgresql-xl, greenplum. Первый года полтора назад был не вполне production-ready, сейчас не знаю, второй используется даже в банковской сфере, но как мне помнится катастрофически не годится для OLTP, только OLAP нагрузка.

Едва пролезет мизинец - это по меньшей мере сантиметр места. Это дофига места. Типичное плотное расположение дисков - расстояние в считанные миллиметры.
Что с ними будет при этом - им всё равно. И крайне не всё равно на собственную температуру. По-дурацки спроектированный корпус может допускать перегрев даже одного диска. Смотрите в мониторинг, оптимальная температура диска и в простое и в нагрузке расположена в диапазоне 35-45С.
Соответственно при плотной компоновке может потребоваться более мощный обдув.

SSD - всё равно, жёстких требований к установке и рабочей температуре нет.

Жесткий диск периодически при запуске выдает ошибку об отсутствии.

Для начала проверить исправность железа.
Особенно диска (MHDD, Victoria), посмотреть SMART.

Затем - при каких действиях тормозит и что в этот момент утилизируется максимально?
Если только у вас не резко вычислительная задача, то ваш добротный 4-ядерный i5 вполне актуален до сих пор. Катастрофической разницы в производительности нет, хотя этими черепашьими шагами в пару процентов за поколение нынешние и побыстрее будут.
ОЗУ - возможно просто недостаточно объёма. Но опять же зависит от задач.

Если у вас не только в prerouting стоят первые 4 правила, но и в таблице маршрутизации созданы routing mark соответствующие, то картина ничем не отличается от одного аплинка. Эти правила как раз и обеспечивают ответ на входящее соединение именно на тот канал, откуда запрос пришёл.

Я для удобства в nat завёл цепочку port_forward, в которую перебрасывал пакеты по правилам in-interface=ether2 и in-interface=ether3. А в этой цепочке уже обычный форвардинг без привязки к реальному интерфейсу.

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether3-gw0
add action=masquerade chain=srcnat out-interface=ether4-gw1
add action=jump chain=dstnat in-interface=ether3-gw0 jump-target=port_forwarding_udp protocol=udp
add action=jump chain=dstnat in-interface=ether4-gw1 jump-target=port_forwarding_udp protocol=udp
add action=jump chain=dstnat in-interface=ether3-gw0 jump-target=port_forwarding_tcp protocol=tcp
add action=jump chain=dstnat in-interface=ether4-gw1 jump-target=port_forwarding_tcp protocol=tcp
add action=dst-nat chain=port_forwarding_udp dst-port=6891 protocol=udp to-addresses=192.168.5.20
add action=dst-nat chain=port_forwarding_tcp dst-port=80 protocol=tcp to-addresses=192.168.7.10

Если с какого-то аплинка порт остаётся закрыт, попробуйте попинговать сам роутер. Если пингов нет на том же самом провайдере - разбирайтесь с routing-mark. Я не раскурил в своё время, как работает эта магия с check-gateway 8.8.8.8.

pgbouncer держит всегда запущенными некоторый пул коннектов (дефолтно, во всяком случае, не в курсе, можно ли его попросить долговременно не держать коннекты вообще). Если вы их утилизируете не все - то будут idle.
А так же это могут быть и старые коннекты, если инициатор соединение ещё не закрыл сам или оно ещё не было закрыто по таймауту. Например, приложение может иметь собственный пул коннектов.

И, разумеется, pgbouncer обрабатывает только те коннекты, которые адресованы именно ему. СУБД он не трогает вовсе, pgbouncer - стороннее приложение, для postgresql - это просто ещё один клиент.

А зачем останавливать репликацию и прочие странные вещи для добавления колонки в postgresql?
Добавляете default null колонку. Транзакционно, мгновенно. Если колонка не должна быть null - то после добавления колонки меняете ей default, затем небольшими пачками обновляете имеющиеся строки, затем drop null.