I see what you mean. This is the view that considers that the database should only be a Persistence Layer and not a Processing Engine. There is a great talk[1]

I see what you mean. This is the view that considers that the database should only be a Persistence Layer and not a Processing Engine. There is a great talk[1] that @felixyz shared regarding the shortcomings of the Persistence Layer approach and the advantages of Processing Engine approach(which we at PostgREST embrace). In summary, having the "business logic" away from the db results in worse performance: more network roundtrips, ineffective cache utilization, wasted CPU cycles in traversing your programming language VM(plus all libs) code paths. Turns out this actually puts more strain on the DB and makes your whole system scale worse. > Hence anathema to those who would treat the persistent store (database) as the source of truth strictly for the one concern which it was designed to address: Managing data. I think marrying these concerns and having them in a single place is more of a benediction for OLTP systems development and maintenance. After all, PostgreSQL has gotten more powerful features over the years and it has evolved to do more than data management(LISTEN/NOTIFY, JIT, etc). I really recommend watching that talk. Btw, slides here[2]. [1]: http://www.prohuddle.com/webinars/ToonKoppelaars/ThickDB.php http://www.prohuddle.com/webinars/ToonKoppelaars/ThickDB.php [2]: https://www.nloug.nl/downloads/ogh20170615_toon_koppelaars.pdf https://www.nloug.nl/downloads/ogh20170615_toon_koppelaars.p...