I think it's a perfectly fine approach in 2025 now that that CI/CD have proliferated and you're less likely to run into a human DBA arbitrarily blocking deployments. It was always the feudal lord mentality of DB operations that made relying so much on stored procedures undesirable.

It'll make a comeback once stored procedures can be easily written in real programming languages using standard tools.

You already can [0]. C, PL/Perl, PL/Python, and PL/Tcl exist out of the box, in addition to PL/pgSQL, which I assume you were implying isn’t a “real programming language.”

[0]: https://www.postgresql.org/docs/current/server-programming.h...

Sure, even PL/Rust is available. But what does the deployment pipeline look like, from version control to a live instance?

That is described in the link, in section 36.18, albeit for C. If you have another language, i assume you get to figure out how to make it work.

[0]: https://www.postgresql.org/docs/current/extend-pgxs.html

Few people seem to be using these. At a guess the dev experience is not great.

Frankly, I think devs need to stop being such primmadonnas about DX. Not everything has a slick UI that does most of the work for you. Take Linux, for example: you have to email your PR as a patch, inline as plaintext to a mailing list. Yet somehow, they manage, and it had an incredibly active community.

Alternative programming languages are all about DX. PL/pgsql is turing complete after all.

It is indeed, but I’ll be the first to admit it’s a bit clunky to use beyond a few variables and actions.

Sorry for snapping. I’m exhausted with devs complaining that some older and well-established piece of tech (Postgres, HAProxy, nginx to name a few) isn’t easy enough to use, and then using something demonstrably worse, or writing their own terrible version of it. Work trauma.