This isn't a dichotomy. That is the point of DDD,SoA,Clean, Hexagonal patterns. Make a point to put structures and processes in place that encourage persisten

This isn't a dichotomy. That is the point of DDD,SoA,Clean, Hexagonal patterns. Make a point to put structures and processes in place that encourage persistence ignorance in your business logic as the default and only violate that ideal where you have to. That way if you outgrow SQL as a message bus you can change. This mindset also works for adding functionality to legacy systems or breaking apart monoliths. Choosing a default product to optimize for delivery is fine, claiming that one product fits all needs is not. Psql does have limits when being used as a message or event bus, but it can be low risk if you prepare the system to change if/when you hit those limits. Letting ACID concepts leak into the code is what tends to back organisations into a corner that is hard to get out of. Obviously that isn't the Kool aid this site is selling. With this advice being particularly destructive unless you are intentionally building a monolith. "Simplify: move code into database functions" At least for any system that needs to grow.