😂

опять же мы не знаем контекста, что там говорил СТО и как и тп и какие у него аргументы

монга под фин решение вопрос спорный, однако имеет свои плюсы и минусы и решать что лучше а что хуже только команде или тому самому СТО

Ну нет, нужно воевать на его поле его же оружием. Сказать, что монга сосёт по сравнению с map[client_id]Client_info - вот где настоящая скорость!

натравите том PG на tmpfs  и будет ин мерори))
а монгу поставите на HDD )

💪

тогда еще и DevOps будут вспоминать добрым словом... )) не так обидно будет

pg  и без этого умеет быть ин-мемори

Если серьезно, то с пг могут начаться проблемы когда таблицы станут оооочень большими в объеме. Тогда уже начнете думать как масштабироваться, может обычным партиц. и решится дело.
Еще важно правильно настроить автовакуум, он должен быть агрессивным, это на будущее.
Обязательно надо следить за распуханием индексов и таблиц. pgcompcator в помощь.
Ну и конечно баунсер ставим
В остальном проблем никаких нет с пг, он отлично держит большую нагрузку, особенно если SSD диски.

А вот с монгой... оочень много жалоб на нее. Короче, скажи своему шефу: "хотите терять данные, клиентов и своих работников — ставим монгу!"

я бы и тут поспорил, тогда уж лучше взять растовский HashMap лол)

Ну это понятно, что раст быстрее ))

это типа "в топку монгу потому что мне так хочется и я что-то такое слыхал" ?
это же не аргументы

автору нужно сделать PoC и доказать чтобы монга для его задачи не подходит

кстати, попробуйте таракана, у него масштабирование из коробки, может вам подойдет по вашему случаю

самый главный аргумент — никто в его команде с монгой не умеет работать

если это так, то тут 2 варианта
1. СТО берет на себя ответственность и говорит - не умеете - будем учиться
2. отказываемся от того с чем не работали

> Типа мы не парясь могли бы овер 2кк запросов в секунду держать.

а сейчас какая нагрузка?

я бы предпочел первый вариант хотя бы до уровня "поглядим, поучимся пару месяцев - посмотрим что выйдет"

1кк, там автор выше писал

2кк в секунду это ошибка видимо