Melkij

https://cdimage.debian.org/cdimage/archive/

В частности, https://cdimage.debian.org/cdimage/archive/11.7.0/...

при наличии уникального ограничения по phone

insert into desc (phone, name, nickname)
select phone, name, nickname from src
on conflict (phone) do update name = excluded.name

Тот самый случай где как раз уместнее просто jsonb.
Для каждой системы будут нужны свои данные, это всё равно у вас будет фабрика в коде для обработки и валидации требований конкретной системы. А поиск по этому json напротив является исключением, а не частой ситуацией.

То есть payment_data: id, user_id, payment_system (enum), data jsonb
В users default_payment FK на payment_data

PS: по моему опыту, лучше сразу предположите что в будущем возможно деление платежа в настраиваемых пользователем пропорциях на несколько кошельков. С задачей такой встречался несколько раз, во всех случаях через несколько лет приходили к задаче "нужно дать возможность пользователю настроить выплаты на несколько кошельков".

create temp table import_data (...);
copy import_data from '/path/to/file' (format csv, ...);
insert into tablename (...) select .. from import_data where not exists (select from tablename where tablename.phone = import_data.phone) on conflict do nothing;

alter user .. set idle_in_transaction_session_timeout = ...

function foo(&$out) 
{
	$out = 'hello!';
}

foo($hello);
var_dump($hello);

max_client_conn в конфиге баунсера - это максимальное число возможных подключений от клиентов к самому баунсеру.
Если у вас max_client_conn стоит, например, 100, а каждый из 20 бекендов попробует открыть по 10 соединений с баунсером - то первая сотня подключений будет успешна, остальные получат ошибку "no more connections allowed (max_client_conn)"
max_client_conn ставится в 10000 и про него надолго забываем. Штука фактически бесплатная, libevent хорошо умеет с таким работать. Но требуется выставить корректный open file limit. Каждый коннект - это файловый дескриптор, если не скорректировать настройки ОС - то будет неприятный сюрприз.

Далее, max_connections базы оставить как есть. Максимум в 100 процессов базы на всего 8 ядер - это и так довольно-таки много, но и урезать смысла нет.
max_user_connections не трогать если нет причин для этого.

pool size 20 на всего лишь 8 ядер CPU может быть чрезмерно. Но далее нужно смотреть уже мониторинг. Сколько реальных процессов базы в работе, очередь ожиданий на баунсере, хватает ли баунсеру процессорного времени (тут скользкий момент, баунсер строго однопоточный и может упираться в производительность одного ядра CPU)