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

Что ты имеешь ввиду под "границей обращения к БД"?

Запросы в тексте, генераторы SQL типа jooq, надстройки типа jdbc templates. Очень много подходов.

СУБД могут иметь точки расширения, типа CLR в MS SQL, которые могут ее дополнить. Например - как вы будете решать задачу Polyglot Persistence , когда вашим сервисам надо будет иметь разные формы представления одной и той же сущности. Допустим - это будет паспорт гражданина РФ. Только одному надо - скан документа, другому - переделанный в Key-Value после  распознавания, а третьему в виде строки в реляционной таблице с провалидированными в ФНС номерами и сроком действия..

Тем, что типы из кода все равно не связаны с данными в БД (так как ORM ничего, на самом деле, не знает про БД).
Это можно решать на уровне проверок при старте (соответствует ли реальная схема той, что ожидает ORM), но это дорого.
Или при генерации и БД и кода по общему метаописанию (но сложно в поддержке и в миграциях).

Ну и вообще миграции и ORM - это очень большая головная боль )

Заметим, что это три разные сущности, а не одна )

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

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

кажется такое есть у всех) привет от AWS

>Заметим, что это три разные сущности, а не одна )     Не а , одна - документ удостоверяющий личность конкретного актора. И они должны быть все консистентны. А вот формы представления разные - в зависимости от характера бизнес процесса.

Впрочем - смешение формы и содержания, классическая ловушка бизнес-архитектора. Да что там архитектора - еще философы древнего Вавилона и прочие последователи - от Конфуция до Гегеля об этом рассуждали ...

EF так вполне умеет, типы описываются в коде (code first), DDL и миграции генерируются автоматически, при старте можно проверить версии базы. Но и далее, все операции, выборки, фильтрации выполняются в строготипизированном виде.

запросы текстом — кстати, еще не проверить во время компиляции

у EF есть нормальные миграции?

пока одна боль от них)

Смотря что понимать под нормальностью

Ну, смотри, это могут быть разные срезы на судьбу одного документа (в котором есть и текст и картинка и подтверждения и т.п.)
И в таком виде оно вполне нормально решается где угодно (хоть в РСУБД, хоть к keyvalue)
И вообще в данном кейсе основная проблема - это аккуратная криптография всего этого.

А почему не равны то . Почему бы не использовать парадигму ООП и дальше, со всей ее метафизикой - наследование, перегрузка, ассоциации, абстракции, инкапсуляции... Опять же вы думаете - что в СУБД должны быть только _данные_ ?  А как же код - а вдруг вы одним select-ом сможете получить сразу экземпляр класса со всеми его рабочими методами ?  И тут же запустить метод на выполнение в привычном итераторе for each...

Миграции не могут быть сгенерированы автоматически ни в одном реально интересном кейсе, увы (

чтобы разные разработчики могли параллельно в разных ветках добавлять свои миграции