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

Ну и в отдельных случаях выручит https://docs.mongodb.com/master/reference/operator/aggregation/lookup/

Postgres - не панацея, с ним свои танцы с бубном тоже есть.

В нереляционных базах данных (Mongo, Redis) одни best practices, в реляционных другие. Может вы не до конца “вкурили” как правильно в mongo данные организовывать?

В реляционных базах можно наложить данных и потом SQL почти с любыми навороченными джойнами справится. В mongo/redis/etc нужно заранее думать как потом кверить будете.

У меня нет ссылки на какую-то книгу с mongodb best practices (може у кого есть?) может если там порыться то там будет ответ на ваши проблемы без переписывания

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

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

но в остальном все данные по своей природе реляционные ведь

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

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

смотря как описывать структуру
можно данные хаотично “грабить”, а можно выделить общее, например, источник или тип.. и можно соответственно этот источник/тип подробнее описать, вынести в отдельную таблицу, и все данные приходящие по определенным каналам (просто пример) будут иметь соответствующие форейдж ключи.

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

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

Чтобы выделеть "общее", надо знать структуру этих данных и быть 100% уверенным, что в тех данных это общее точно пристутствует.

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

Когда нужен большой higload то приходится чем-то жертвовать. Жертвуют консистентностью данных (монга или редис быстрее потому что они не гарантируют целостность данных и не проверяют foreigh keys и еще много чего не делают) и вторая жертва которую ты делаешь это возможность легко делать сложные запросы.

ну вот на моем опыте монга не быстрее от слова совсем
у меня долгие годы был MS SQL и монга для других задач.
Монга на больших выборках просто умирала, особенно когда из огромной коллекции надо по определенным условиям вынимать циклично данные со skip и limit.
Она вообще еле вывозила.

Мелкомягкую базу под это дело тянуть мне не хотелось, я просто взял постгрю попробовать и был приятно удивлен.

CAP теорема об этом - никакая база данных не может давать все три параметра - Availability + Consistency и Partition Tolerance. Реляционные базы не Partition Tolerant. Поэтому кому очень надо партиционирование/шардинг/etc берут нереляционки https://habr.com/ru/post/328792/

у вас точно индексы были?
причем правильные индексы.

индексы точно были
подробности уже не вспомню, дело еще 2018го, там уже трудится постря, настолько хорошо, что я тот сервис уже пару лет почти не трогаю, только зависимости обновляю 😄

но наверно мы все делаем в основном средние проекты где даже не доходит до хайлоадных проблем и понимания что тут mongo/redis вывез бы лучше чем реляционные

так монга быстрее при записи/обновлении, а не при выборке

Ну хз, ибо у меня на проде база 50Тб с индексами, которые весят по 100-200Гб и запросы вполне укладываются в 1с.

Вы когда-нибудь на ней делали запрос с .explain()?

я бы не сказал что при записи она сильно быстрее

У меня на постгресе сейчас таблица многомиллионная с 10 полями, из них с индексами где-то 6 (по разным параметрам приходится из этого барахла вытягивать статистику)

То постгрес отрабатывает моментально, в общем как и timescaleDB которой пока что тоже доволен.

Но я не исключаю вариант что может либо версия старая монги была, либо что-то не так настроено было