JDBC is like assembly language. Back (several decades now!) software companies used to brag about the how their product was efficient because it was written in assembly language.
Well, it probably was - back then, when compilers rather stupidly translated line-by-line from high level to machine code. But that changed somewhere around 1985 when I started seeing products like IBM's Pascal/VS compiler, which not only generated frighteningly efficient machine code, but could re-optimize the code start-to-finish every time it compiled - something that would be cost-prohibitive to do on an assembly-language program of any size.
I also endured my share of non-optimal bubble-sorts and linear searches working with assembly-language code. Because while we weren't as pressured for time back then, even a simple Shellsort required about 3 times as much work to implement (and sort/search libraries were scare back then).
These days, not only do compilers do a superlative job of optimizing code, environments such as
Java's JIT can actually analyse code for efficiency
while it's running and re-optimize the code on the fly based on the workload. Under some circumstances, Java can outperform C/assembly code because of that.
A similar situation exists between JDBC and ORMS. I've seen benchmarks that put the throughput for ORM-based tests at double the rate of their raw JDBC equivalents. Again, that's because when things begin to scale, machines can juggle more variables than humans can and machines can afford to do more work on optimizing than humans can - especially since the watchword of the day is usually "Just Git 'er Dun!"
Your Mileage May Vary, of course. If you have a rigidly captive environment, JDBC may outperform an ORM, especially when it's a smaller environment. The overhead of an ORM, like the overhead of a JVM, is substantial, so first your project has to be big enough to justify the start-up costs.
More important than the platform, however, is what you do with it. Choosing your algorithms (and in this case, your schema) can make a world of difference. In fact, much of the success of the NoSQL movement comes from the enhanced throughput that you can get when forgoing the advanced features that SQL databases offer - especially table joins. A favorite case in point that I often quote was a product where the data was
almost but not
completely pre-sorted. That's a nightmare scenario for Heap and Quick Sorts, and not much better for the much-maligned bubble sort. But a Shellsort was ideal for the data in question. The efficiency of the algorithm vastly dwarfed any efficiencies of automated or manual code generation.
