Да, так и есть. Уместность такого подхода сильно зависит от того, насколько приложение датацентрично. Если это OLTP - то нужна транзакционная БД как ни крути. Если брать БД, то брать крутую. А если взял крутую - так надо брать всё, что она даёт, и очень велика вероятность, что, оказывается, ничего другого и не нужно.
Внезапно выясняется, что ты можешь производить там точные вычисления с запредельным кол-вом знаков после запятой. Идеально для подсчёта денег. Собственно, много банков это и используют.
Дальше выясняется, что всё, что происходит в хранимке - транзакция. Так что можно сделать таблицу истории пополнений, инсерт в которую провоцирует реферальное начисление, изменение закэшированного баланса, автоматическое подключениие услуги. Во внешнем клиенте это всё выглядело бы дико убого - надо стартануть транзакцию, посылать по одному запросу, закрывать транзакцию. А тут просто три запроса подряд.
Потом выясняется, что постгрес умеет и в реалтайм - LISTEN/NOTIFY.
А ещё у него есть вьюхи - и на апдейт/инсерт/делит во вьюху можно повесить триггер!
А ещё у него есть материализованные вьюхи... а ещё, а ещё... и в итоге ты обмазываешься всеми этими фичами, и прилипаешь к нему намертво. Перейти потом сложно. Но на построениие всего этого у тебя ушло раз в 5-10 меньше времени и сил, работает это всё намного стабильнее и быстрее.
Брат, плюсую дико тебе. Относительно недавно приходилось писать детский процессинг, описал всю доменную область в бд, накинул хранимки, вьюхи, материализованные вьюхи, слушатели. Поставил на чтение перед постгресом хасуру со всякими политиками на чтение и второй сервак аполло для вызова мутаций через готовые хранимки. По ощущениям это был один из самых эффективных проектов с точки зрения трудозатратности. Не надо открывать никаких транзакций, описывать в коде, чтобы вместе с переводом списывалась комиссия, все уже решается на уровне базы, вызывай хранимку и все. Красота
Бэк выступает в качестве тонкого клиента к бд, где уже хрянятся все знания и правила работы предметной области
