lega

Сколько места сэкомомиться

- В json идет доп. расход места на хранение имен ключей, структуру и синтаксис, (числовые) значения в строковом представлении.
+ Экономия может быть за счет того что нет резерва для строк фиксированного размера.
+ Так же экономия может быть за счет редких полей, которые нужны не в каждой строке таблицы.
Так же json можно хорошо сжать, но поддерживает ли это psql...
Результат зависит от типа данных (и метода хранения).

2.Производительность

В теории должна быть ниже т.к. кроме выделения строки в таблице, нужно выделять место под этот json + его валидация.

3.Какие еще плюсы и минусы

+ Можно хранить сложные структуры данных
+ Позволяет делать прозрачные миграции (развитие проекта без миграций)
- Требует больше места по сравнению с простыми колонками (числа/даты)

Я бы залогировал время выполнения всех запросов, составил топ самых медленных и начал с верха разбирать каждый запрос.

Все таблицы соответствуют норльманым формам, индексами покрыты (в т.ч. и составными) большая часть запросов SELECT.

Большое кол-во join-ов снижают производительность, вложенные селекты могут убивать производительность т.к. на них нет индексов. Так же зачастую разработчики ставят неправильные индексы что дает не максимальную производительность - не достаточно просто "установить" индексы на нужные поля.
Но это все разработчику, админу наверно остается следить что-б памяти хватало, да в cpu/io не упиралось (ну и может статьи по тюнингу почитать)

А что если keyword сделать массивом (или использовать tsvector), тогда должен работать поиск на точные совпадения, а значит (возможно) и заработает группировка. В монге так "облако тегов" работает нормально.

В вашем случае наверно самым оптимальным будет параллельное вычерпывание сортированных данных (по одному проходу по каждому серверу и одной записи на каждую строку), если % пересечений высок.

А вообще почему не сделать шардинг?, сделать индекс (например) по 3-м полям и заливать данные в нужные сервера (типа всех alex на 1 сервер, max на 2-ой), что-б не было пересечений, таким образом данные мержить не нужно будет + экономия памяти.
Так же непонятно наличие мастер базы, вполне возможно её можно было избежать.

Если VPS в разных датацентрах, то какие последствия?

Должно работать нормально, я в одном проекте сделал ноду на домашнем компе с динамическим ип (через OpenVPN) для бекапов, работало стабильно.

Многое зависит от отчетов. Например для вашей задачи хранить сырые данные вообще не нужно.

Если отчеты ещё не определены или все же нужны сырые данные, то можно сделать партиционирование, например складывать все логи по одному игроку за один день в один документ в бинарном виде (time_delta, action) при этом зажать в gzip/zlib/...
В итоге из 500Гб может получится 5Гб, а скорость вырастет за счет легких индексов и меньшего кол-ва передаваемых данных/документов. - недавно делал подобное.

Так же можете сбросить userFlag в 0 для коллекции - сэкономите памяти, при этом монга не будет делать доп. резеривирования в каждом документе.