What, huh? Aren’t stored procedures SQL in function form?
That’s how everyone used to build apps before Rails came along and made everone think putting biz logic into a slow server side language was a good idea.
IMHO and I might be entirely wrong but placing and coupling all that logic into the database seems like a bad idea and it's not a question of speed, it's a question of separating responsibilities. Also, for the case shown in the article, it seems all right for a "hello world" kind of thing. For something complex or prone to deep changes (like most of software projects I've been involved with), this seems like a true nightmare.
I’m sure you know this but the reason for taking computation off the database is that it’s much easier to horizontally scale a stateless middle tier than it is to scale a sql database.
Some DBAs I’ve worked with even advocated for taking sorting off the database. I wasn’t entirely convinced by that one.
My server side language in this case was Scala, so it wasn’t slow, just memory hungry.
Is it really easier to scale a Rails or Node app than Postgres (Scala might be an exception)? And how many pieces of software actually ever reach the kind of scale where database is the bottleneck? For many use cases, biz logic in the database will absolutely smoke doing it on server side due to query planner optimizations.
That’s how everyone used to build apps before Rails came along and made everone think putting biz logic into a slow server side language was a good idea.