Having seen quite a lot of 'roll your own' solutions for wrapping queries: they were almost all unstable, inefficient messes that have a tendency to pick up lots of ad-hoc functionality. I'm not particularly fond of Hibernate but at least it's well tested and efficient for what it does and does things in a standard way so you can mostly look up stuff in the manual instead of guessing your way through a homebuilt framework.

> depending on project since it gives you absolute control

Absolute control to hunt down your own bugs, instead of using something that is an industry standard and any competent programmer jumping to your project can be up-to-speed with it instantly..

Very few developers are competent with hibernate, many fewer than with sql. Writeback cache nature of hibernate makes it very complex, order of operations on the app won't match order of operations in the DB.

Even an "industry standard" framework can get in the way. Given the constraints of executing efficient queries; handling errors and timeouts on the application's terms; and enforcing concurrency and transaction handling policies even a "good" ORM can be more a problem than a solution.

All of those will be worse off by hand-made “solutions”. Especially that you are not forced to use ORM for everything. Use it for like 90% of your generic db usage, and use its in-built escape hatches for the rest, like native queries or go straight to the db driver if needed.

In my experience I‘m better off not touching an ORM at all