Все зависит от задач. Для простых систем наверно возможно и так писать, но очень спорно. В мем случае вариант абсолютно не рабочий. К слову об алгоритмах, вы когда-нибудь делали поиск кратчайшего пути по графу на plpgsql? Это дикие тормоза, скорость по сравнению с реализацией на го примерно в 600 раз медленей, с питоном в 100

Никто не мешает расширить узкие горлышки постгресу на другом языке :) там щас есть даже яваскрипт для хранимок

А таких задач очень много, прошли те времена когда нужно было остатки на складе собрать. Теперь большие данные и матмодели рулят. Как прогноз собрать? Как интегрироваться с сервисами, и таких вопросы как очень много. Вообщем для простых задач можно но спорно, для остальных точно не вариант.

Ага потом лови мышей, как отлаживать это чудо?

делегировать скопилированным библиотекам, как это делает например pgcrypto

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

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

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

Было интересно чем закончится ваш небольшой холивар, Просто хочу уточнить в варианте ДА/НЕТ.  У вас была задача поиска в вагоне картошки картошки с тремя глазками и решив ее вы убедили себя и убеждаете оппонента что проще вывалить весь вагон куда ни будь на клиента и там перебрать с хорошим освещением и лишнее вернуть обратно, чем разложить картошку в вагоне и брать то что нужно только?

Хуже всего когда к вагону претензии у нескольких лиц сразу, например одному нужны картошки с тремя глазками, а другому нужны временные срезы по загрузке вагона за 5 лет в реальном времени.

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

Не пугайте молодёжь!

Если речь идет о возрате нужного количества данных то чаще всего справиться и SQL. Хранимые же процедуры используют для какой либо логики, например, у меня с их помощью формируют html

Хранимые процедуры на SQL? Бизнес логику в них держать? Ну-ну, успехов 😉

Хранимые чаще всего используются для триггеров, а так же для вызовов на запись, это особенно удобно, когда запись должна модифицировать и просчитывать кучу всего, собирать статистику, писать в журнал, детектить кондищены например для поиска абюзеров.

Это да. Но не бизнес логику.

это тоже бизнес логика, а вот шаблонизатор для хтмл это не бизнес логика

На SQL вообще бизнес логику писать вредно для здоровья продукта. Поэтому все пользуются hibernate etc.

Если бы хранимки можно было делать только в виде чистых функций, было бы гораздо проще, но увы, так, бизнес не бизнес, все равно это такое себе на практике, особенно когда пытаются делать тот же шаблонизатор

hibernate вообще не про написания какой либо логики