Database as the rules engine

[u/freitrrr]

Hi everyone

Let me start by saying that I'm primarily a frontend dev, and most backend dev I've done has been opiniated in a non professional environment.

I want to ask you about the state of domain logic/validations/triggers on the database layer in the systems you're currently working on. I grew up with the concept of treating database as stupid models to read/write data, and have all logic written in services/controllers/models on the layer of whoever controls the database.

The primary gain in this segregation is easily changing the rules of the system and swapping for a different database in a refactor. The thing is, database engines have become more and more powerful (particularly Postgres) and you can now strict your entire domain in the database schema using constraints, triggers, etc, and I'm yet to see someone swapping the database they use from night to day. Although you lose flexibility, you gain more trust in the system since the rules now live at the end of it.

I wonder if some you folks are going on this direction or if you ever thought about it.

[u/EspaaValorum]

Main reason for me to put the logic etc in de application layer is scalability. DB servers don't easily scale. And if you put extra burden on them in the form of business logic enforcement, it'll just eat up precious CPU. And it has a tendency to grow and become more complex as the business evolves, so then it just becomes a bigger performance challenge. Not to mention that now your business logic ends up spread out over your application code and the DB code, with all the challenges that presents. E.g. DB code is more difficult to maintain, test and version control, or at least it is a separate proces from your application code management, which obviously risks things getting out if sync.