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

Я рассматривал докер как единую платформу для бэка с нативными модулями (независимость от ОС, версии ноды).
Да, пишется с N-API и вроде всё ок
node-gyp- ужас

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

Если мы конечно не говорим о потоке данных через aws лямбды :) там свои правила игры

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

А вот куда выносить работу с данными из ноды, если не в базу данных? Я просто до мозга костей нодовый, мне правда интересно, как ещё можно

юзать ноду как прослойку доступа к данным мб

У нас всё в java-бэках (мы же финтех). И уже переезжали с Оракла на Постгрес :)

Ну вот да, но если есть инструменты, которые представляют из себя ту самую прослойку, только уже готовую, то зачем вообще нода?)

чтобы ботов для вконтактика пилить, как зачем ?

Оооо круто, и как переезд прошёл?) Просто заменили БД?)

Нода прекрасный API Gateway ну и конечно же SSR

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

Был большой и долгий проект, не уверен, что в год уложились. Но вывезли.

Но этим занимались бэкендеры, я особо не следил, у фронтов и так головной боли хватает. Одно создание платформы на nest уже больше полугода жизни у меня съело.

А если не секрет, есть ли у вас какие-то ограничение на использоване ф-ций постгреса? Как ни крути там очень много фишек, которых нет в других субд. А у вас, насколько я понял, политика, что БД - тупое хранилище, которое можно заменить в любой момент. Соответственно, как-то должно огранчиваться использование специфичных ф-ций?

Понял, походу мой вопрос не в тему)

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

Хм, а можете составить 2-3 важнейших правила для нового проекта на ноде (не активно, но всё же работающего с деньгами) ?

Всю бизнес-логику переносить в бэкенды :)
Не дублировать валидации, не считать комиссии на клиенте (в браузере)
Всегда должен быть только один источник правды

А как общаетесь с бэкендом?