Wether it makes sense to put business logic in procedures really depends on what's involved in "business logic". For data-heavy apps with very complex schemas,

Wether it makes sense to put business logic in procedures really depends on what's involved in "business logic". For data-heavy apps with very complex schemas, your code can actually get more readable inside stored procedures. I used procedures for a content creation pipeline/headless CMS app that had flexible workflow templates (those also lived in the DB). It works quite well, and is simpler and more readable than most common backend code and much faster to develop. If you need to trigger async stuff, like network access or data processing, one pattern I enjoy is writing to a log-ish table that gets picked up and processed later by a separate service. This is nice for emails and other types of notifications: your users get a log of sent emails, and you can very easily do it inside a transaction. If the complexity is on the querying side, then you can get a lot of mileage from views. If you need caching for that, materialized views really help. However: If you're doing complex numeric/algorithmic stuff, rely on external libraries, or has just plain too much business logic... then doing things in a separate service is definitely better, no question about it. Triggers, I'm personally not a fan.