terrier

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

локация пользователя по ип или от браузера
postgis.net

Да у него полно применений из-за того что легкая vm и он удобно встраивается.
Из примеров это скрипты в играх и софте, сам я на нем под микроконтроллеры пишу, так же в Tarantool он используется.

вообще можно создать при помощи C++ красивые приложения, или без C# некак?

Нет, только страшные. Видимо вам придётся выбрать другой язык.

Микросервис - это, скорее, не библиотека, а автономный (ключевое слово!) небольшой модуль, выполняющий какие-либо функции. И делается он так, чтобы его можно было свободно перенести не то, что в другую БД, а даже на другое оборудование, поменяв для этого лишь настройки связи с другими частями приложения. Или масштабировать, если задействовать несколько серверов одновременно - каждый со своим экземпляром микросервиса. При проектировании микросервисной архитектуры нужно детально описывать связи между модулями (в т. ч. микросервисами) и передаваемую информацию - вплоть до полного протокола обмена.
По Вашему описанию применение микросервисной архитектуры вряд ли можно считать разумным. SQL-сервер всяко лучше разберётся с выборкой данных из связанных таблиц, чем самопальная архитектура. А масштабироваться при большой посещаемости вполне можно обычным кластером с балансировщиком нагрузки, данные (они же сравнительно редко обновляются?) при этом передавать через репликацию или просто скриптовым деплоем изменений в БД по всем серверам.

Вы какой то идеальный план нарисовали. Когда вы СРАЗУ видите игру КАКОЙ ИМЕННО она будет.

В реальности все эти пункты постоянно итерируются.
Это может быть и сотня итерация (сотня изменений) пока игра выйдет.

PostgreSQL

Открываете сайт каждой компании из вашего же списка, ищете там "карьера", "вкаансии" и т.д. и вдумчиво читаете.
В крайнем случае - линкедин и их эйчары в помощь.

Никаких.

Мой друг, также программист 1С, рассказывал о ситуации у них в конторе, где он был свидетелем, как резюмэ 2 кандидатов с солидным опытом разработки были отброшены почти сразу, так как обоим было 43-45 лет. И директор IT-отдела сказал тогда другу: "ну куда мы будем таких брать? Нам нужен молодой, энергичный".

такие завораживающие истории существуют в любой профессии.
также существуют жуткие рассказы, когда не берут слишком молодых или слишком женщин или слишком нерусских или слишком без прописки или еще много по каким признакам.
но мы-то понимаем, что всё это ерунда. это естественные препятствия, которые должен преодолеть желающий и не более того.

Разнесите запрос на представления, временные таблицы, хранимые функции, возвращающие табличное значения и т д.

В общем, попытайтесь создать некоторую архитектуру. Ведь наверняка подзапросы из этого сложного запроса используются где-то еще. Убьете двух зайцев: и читабельность будет выше, и повторное использование кода оптимизировано.

Классический вопрос из серии XY Problem.
Вместо того чтобы писать "я не знаю что мне надо, но вообразил что мне нужен шардинг, поэтому расскажите как им пользоваться" надо писать "масштабирование мне требуется по такой-то причине и с такими-то условиями. подскажите наилучший вариант".

И тогда тебе подскажут ответ, в порядке частоты причин, по которым задают этот вопрос:

1. Нет, бояться миллиона записей не надо. Mysql потянет во много раз больше.
2. Сделать репликацию мастер-слейв, с нужным количеством слейвов.
3. Возможно, под какие-то условия подойдет и шардинг.

Update.
Как и ожидалось, все свелось к п.1.