And yet, i once talked with a developer (who primarily worked just in procedural SQL), who claimed that having a separate back end oftentimes makes no sense wha

And yet, i once talked with a developer (who primarily worked just in procedural SQL), who claimed that having a separate back end oftentimes makes no sense whatsoever: the endless shuffling around of data, transforming it in the back end, especially for something like reports. While there is some merit to either end of the spectrum (e.g. not thinking about the schema or SQL much on the one end, letting the ORM do the heavy lifting, vs doing a large amount of in database processing), i've found that preferences in that regard largely depend on what any particular person is familiar with. Personally, i think that processing data within the database makes sense for large bulk operations, however otherwise databases are largely unsuitable for anything apart from being the data layer for CRUD, or analytic queries - whenever you try to create any sorts of complex algorithms in SQL, without fail you'll end up with code that isn't readable, isn't extensible and doesn't compose as well as even Java libraries would. Databases will also lose out on logging, debugging (e.g. breakpoints) and oftentimes scalability - it's easier to scale instances of a REST API horizontally than it is to scale a database engine, given that most of them scale vertically. Of course, Yugabyte or TiDB might try to be exceptions in regards to my last point, but the latter doesn't support stored procedures and triggers altogether, so scaling can have serious limitations: https://docs.pingcap.com/tidb/stable/mysql-compatibility https://docs.pingcap.com/tidb/stable/mysql-compatibility On the other hand, trying to do everything in the app is just asking for horrible schemas that have been automatically generated and aren't as well normalized as they should be, awkward framework specific ORM functionality and pitfalls (Hibernate lazy/eager init in particular), as well as having an insane amount of opportunities to run into the N+1 problem or issues with how linked data is represented and persisted. In summary, there are pitfalls with either approach and i'd just suggest that any team consider what they know how to use better and what better fits their needs. So far, in my experience, it's mostly doing apps within the application, not shying away from SQL when necessary, but also considering the very few use cases when using stored procedures or triggers indeed makes sense, and then looking for ways to comment them as much as possible. Testing them, however, is another story, which should reflect upon certain shortcomings: https://www.jetbrains.com/lp/devecosystem-2021/databases/#Databases_do-you-have-tests-in-your-database https://www.jetbrains.com/lp/devecosystem-2021/databases/#Da...