Одно "но" забыли - диски сегодня (системы хранения) - самая дешевая часть компьютера. Пока СУБД думает как упаковать данные в сегмент диска - уже сто раз DMA сможет скопировать блоки между устройствами, не загружая _ни одного такта_ CPU. А для баз в оперативной памяти - вообще неважно выравниваение записей строк по размерам/сегментам - там прямая адресация - сколько надо байт зачитать, столько и сделаем - да еще плюс превратим данные в код а код в данные (как в ООП базах обычно применяется). В оперативной памяти даже B-tree индексы неинтересны, там T-индексы применяются...

Я вот знаю, что для монги там можно прям LINQ заюзать

pg вообще считаю наидермовейшая СУБД с кучей технического долга и ленивыми и с неадекватной самооценкой - разработчиками в комьюнити. Одна радость что опенсорс..

Одно из веских оснований, что MongoDB , кроме интересных фич по документоориентированным обьектам, вполне прилично финансируется из разных фондов. Получила более 200 M $ инвестиций, что улучшает качество продукта и делает его более пригодным для "кровавого энтерпрайза". Хотите работать с опенсорсом . разрабатываемых какими то сумасшедшими асоциопатами и делающим его "за еду" в минуты только хорошоего настроения - флаг в руки...  но я бы подобные решения к себе в портфель не брал бы..

А где-то там ниже FTL с пачкой алгоритмов + кеши + свой object storage. И всё это за интерфейсом block device

В ORM прямой поддержки jsonb вроде бы нигде нет. Обычно можно прикрутить свою, если зачем-то вообще нужен ORM (обычно не нужен).

Но в PG можно делать и глубокие индексы и богатый условный поиск, делов-то.

Не кеши а реплика. Кеш это недоделанная "односторонняя" реплика. А технологии CDN сейчас сильно в интернете продвинулись (спасибо pornohub-у 😉 )

Вы считаете, что использование ORM нигде не имеет смысла?

Всё так, чего только fsyncgate стоит. Но работа ведётся, в том числе по пути aio+dio

Единственное преимущество RDB - что она _универсальная_ На ней по сходной методологии можно хранить и обрабатывать сущности в разном представлении. И разумеется поддерживает ACID   А дальше пошли уже "особенности" - масштабирование. специализированные форматы сущностей (документы, кортежи, графы, изображения) и пр - которые требуют более узконаправленного решения.  NoSQL в моей парадигме все же надо переводить - Not only SQL !   Хорошие исследования на эту тему лучше почитать у ИСП РАН (лаборатории проф С.Д. Кузнецова), чем на habr-е , там более глубокие и рациональные рассуждения без этого маркетингового булшита сейлзов. Тут например https://www.ispras.ru/publications/nosql_data_management_systems.pdf

Почти везде это скорее антипаттерн и гарантированные проблемы. Есть исключения, но они редко оправдывают использование ORM.

Спасибо за ссылку. Ознакомлюсь.

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

Есть один нюанс, академики за эксплуатацию не овечают

Почему - как раз тренд - делать Data as Service, в какой там форме они лежат в persistence layer - уже маловажно. Хотите - в 4НФ лепите "по классике" в OLTP, хотите денормализуйте - если нужна высокая реактивность на чтение..

Не работает, так как от того, как данные хранятся - принципиально зависят методы работы с ними (производительность, подходы к фильтрации и т.п.). Т.е. для каких-то очень простых решений, наверно, можно абстрагироваться от persistance layer, но как только или сложная логика или не очень низкая нагрузка - уже приходится хорошо понимать про то, что под капотом.