jOOQ vs. Hibernate: When to Choose Which
Hibernate has become a de-facto standard in the Java ecosystem, and after the fact, also an actual JavaEE standard implementation if standards matter to you, and if you put the JCP on the same level with ISO, ANSI, IEEE, etc.
This article does not intended to discuss standards, but visions. Hibernate shares JPA’s vision of ORM. jOOQ shares SQL’s vision of powerful querying, so for the sake of the argument, let’s use Hibernate / JPA / ORM interchangeably, much like jOOQ / JDBC / SQL.
The question why should anyone not use Hibernate these days always shows up frequently – precisely because Hibernate is a de-facto standard, and the first framework choice in many other frameworks such as Grails (which uses GORM, which again uses Hibernate).
However, even Gavin King, the creator of Hibernate, doesn’t believe that Hibernate should be used for everything:
If that’s the case, are there any objective decision helping points that you could consider, when to use an ORM and when to use SQL?
Discussing on a high level
First off, let’s bring this discussion to a higher level. Instead of deciding between Hibernate and jOOQ as concrete implementations of their own domains, let’s think about ORM vs. SQL, and their different use-cases.
When deciding between an ORM (e.g. Hibernate) and SQL (e.g. jOOQ), the driving question that you should ask yourself is not the question of project complexity. Some of our most demanding customers are using jOOQ on medium-sized schemas with thousands of tables / views. Often, those schemas are extremely normalised and sometimes even deployed on as many as six different RDBMS. jOOQ was specifically designed to work in these scenarios, while keeping the simple use-case in mind as well.
So, instead of thinking about project complexity, ask yourself the following questions:
- Will your data model drive your application design, or will your application design drive your data model(s)?
- Will you do mostly complex reading and simple writing, or will you engage in complex writing?
SQL really shines when reading is complex. When you join many tables, when you aggregate data in your database, when you do reporting, when you do bulk reading and writing. You think of your data in terms of set theory, e.g. your data as a whole. Writing CRUD with SQL is boring, though. This is why jOOQ also provides you with an ActiveRecord-style API that handles the boring parts, when you’re operating on single tables (Jason mentioned this).If, however, your writing becomes complex, i.e. you have to load a complex object graph with 20 entities involved into memory, perform optimistic locking on it, modify it in many different ways and then persist it again in one go, then SQL / jOOQ will not help you. This is what Hibernate has originally been created for.
I believe that data is forever. You should *always* assume that your database survives your application. It is much easier to rewrite (parts of) an application than to migrate a database. Having a clean and well-designed database schema will always pay off down the line of a project, specifically of a complex project. See also our previous article about the fallacy of “schemaless” databases.
Also, most projects really do 90% reading and 10% writing, writing often not being complex (2-3 tables modified within a transaction). This means that most of the time, the complexity solved by Hibernate / JPA’s first and second level caches is not needed. People often misunderstand these features and simply turn off caching, flushing Hibernate’s cache to the server all the time, and thus using Hibernate in the wrong way.
If, however, you’re undecided about the above two axes of decision, you can go the middle way and use jOOQ only for reporting, batch processing, etc. and use Hibernate for your CRUD – in a CQRS (Command Query Responsibility Segregation: http://martinfowler.com/bliki/CQRS.html) style. There are also quite a few jOOQ users who have chosen this path.
- Throughput vs. Complexity – When should I use an ORM? by Mike Hadlow
- Why should you use an ORM? by Bill Karwin
- Are there any good reasons not to use an ORM? on Stack Overflow
- Why should you use an ORM? on Stack Overflow
|Reference:||jOOQ vs. Hibernate: When to Choose Which from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog.|
Also another point that is important to consider is that JOOQ requires a license if you want to point it to Oracle, SQL Server or Sybase DB. This comes with tradoffs: great support, active development but non-negligible cost.
The cost is actually rather negligible as jOOQ ships with a floating developer license, and an included, royalty free and perpetual distribution license.
Of course, I’d like to dare you to calculate the total cost of ownership of using Hibernate: It’s “free” up front but you won’t get bug fixes easily unless you have a support subscription. So, what exactly is the difference in long term pricing?
Hi Lukas, you are right I agree and I don’t want to give negative impact with my comment :). I like JOOQ, I like the fact it’s in github and also your great support and care as mentioned. Also your presence in the Java (and Java interaction with DB) community with great articles and initiatives. So if anyone reads this, please try out JOOQ since it’s a great product promoting DSL with fluent builders :)
Oh, I didn’t imply any negative impact :) But I do a lot of work helping developers understand the topic of “total cost of ownership”. Low/no upfront prices are a mere marketing strategy. In the SaaS ecosystem, people call this “freemium”. Some vendors call this “Open Source”, but it doesn’t really matter.
In any case, thank you very much for your nice words!