Ну, там сильно зависит от коэффициента масштабируемости, от ограничений на деградацию.
Тем более что идеальной горизонтальной масштабируемости даже на key-value практически не получить.

Поэтому я и удивился, что почти всегда не стоит использовать ORM

А в этих решениях нет потребности в арх.решении по выбору persistance, там все тривиально и реализуется на чем угодно.
Но так как они простые, то ORM там тоже скорее будет мешать, нежели помогать.

Ну что-то выбрать то нужно)

Ну нет, это далеко не серебрянная пуля. Но для многих задач это "первый кандидат на решение", это да.

Угу. У меня вот сейчас в проекте нет ни одной RDB, но это был сложный выбор (

Это дилетантство. Природа "мусора" не держит - ушло бы в процессе эволюции. И целое направление открыли - Dark DNA - теневая ДНК - где рассматриваются цепочки в десятки и сотни тысяч геномов, вместе делающий оркестровку какой то "фичи".. p.s. нет - особая субд, так как нужна скорость выборки секвенсов.. Не брут форсом же сверять. Вспомните алгоритмы Кнут-Моррис-Пратт (КМП), и Боуер Мур (БМ).. Кстати и MongoDB это тоже умеет https://www.mongodb.com/press/genomics-england-uses-mongodb-to-power-the-data-science-behind-the-100000-genomes-project

Да, но нет. Пока еще никто не умеет нормально утилизировать 1mln IOPS, так что качество работы с дисками имеет очень большое значение.
И да, тут у PG все не очень хорошо (но у большинства NoSQL еще хуже).

Это ты, наверно, с Oracle мало работал )

Так я и прошу привести пример, где Mongo не хуже (я, кстати, даже знаю несколько очень важных плюсов монги - но про них что-то никто даже и не заикнулся)

И последний, когда узнают про ORACLE RAC  и прочие Golden Gate...

Я бы сказал, что этот совет относится к любым решениям, не только к СУБД и не только к PG.
Обновление мажорных версий без останова - очень больная тема (

"Дилетантство" - это не мое мнение. По поводу мусора - это мнение многих ученых от таких как Де Вааль до Дробышевского. Природа не так совершенна. Насколько помню, если это выкинуть, то человек похудеет на 10кг :)

Обычно пг рассматривают как типовую замену ораклы\мссиквел\дб2

Ох, вот я как раз достаточно знаю про RAC и GG - и предпочту с ними никогда не сталкиваться )
Oracle - страшная штука...

Лет пять назад при наличии выбора я взял бы DB/2
Но давно уже не смотрел внимательно, так что про сейчас не знаю.
Ну и, конечно, имеет смысл смотреть на TCO, а это всегда не просто.

Впрочем, мой текущий стек совсем экзотичен )

по мне так Redis и Mongo прекрасны попсовостью. Надеюсь я больше не попаду в стартапы, но вот для них это самое то. Все что умеет лаять и мяукать, заодно знает Redis и MongoDB. Причем кроме разработки, еще и Ops-часть. Это очень простые решения, очень документированные и предсказуемые на сегодня. Они мало потребляют ресурсов, это удобно для dev-задач особенно (запустить локально CouhBase  в кластерном режиме - ну такое себе...). Прекрасно подходят для проектов где не думают. Где нет денег на архитектора, где СТО назвал себя так сам или его назвал так основатель бизнеса, хотя до этого СТО сайты делал.

По мне - это идеальная ниша данных решений.

Зачем - если есть аппаратные платформы, затягивающие чуть ни 1TB RAM и там строящие свои представления в 2,3 и прочие N-модели., ну совсем отличающиеся от реляционных Как с утра закачали с диска в оперативку, а вечером выгрузили обратно на диск. А надежность поддерживается аппаратными средствами. Есть еще и спецпроцессора, которые могут обрабатывать данные IoT "на лету" - без отправки в ЦОД - типа процессоры на  нейросетях. Там уже можно вкорячить в инферно весь imagenet и обсчитывать любые обьекты на каком то ResNet18 со скоростью 50 fps в разрешении 4K - а в СУБД скидывать уже ФИО и фото попавшегося "счастличвчика"..

Ну, для стартапов - наверно да. Когда сразу делается на выброс, когда квалификация всех разработчиков мало отлична от нуля и ничего хорошего все равно сделано не будет - то все равно, что брать.