There is no one-size-fits-all, but most of the time I would be against SP because:

1) SPs usually mix persistence concerns with business logic. Making it harder to understand business intent. I find objects much more expressive than raw data. Sometimes you want to concentrate on the plain logic, without worrying about how something gets saved. Also you will not have to rewrite everything if you ever want to change how something is stored. Sometimes people switch from mysql to pg, or even doc or kv database. Keeping business logic separate enables this. And good ORM enables this separation.

2) Refactoring tooling and unit tests. SPs are lacking here significantly compared to general purpose languages.

3) Business logic outside of DB allows easier horizontal scaling.

In my experience, the application framework changes much more often than the database.

PHP, ASP, ASP.NET, Angular, React, Django, whatever. Pick a year, pick a framework. The database stays steady.

I agree. But I found that approaching it _as_if_ database will change makes for a more focused model. Same goes for UI frameworks. Basically thriving toward Hexagonal architecture, without being too dogmatic.

Cool! I do this, but I haven't seen anyone else do it. Is any of your code public?

I wrote about it at https://sive.rs/pg

and posted my SQL shopping cart at https://github.com/sivers/store

Please contact me if you'd like to share tips: https://sive.rs/contact

No I don't really have any public code.

I read your blog post and I agree 100%

The database is the easiest place to code business logic that pertains to the data. Write it once, it's available for all client applications.