SQL Zone is brought to you in partnership with:

Rick has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

Is Hibernate the best choice?

  • submit to reddit

Is Hibernate the best choice? Or is the technical marketing of other ORM vendors lacking?

Recently Jonathan Lehr posed a question on his blog: "Is Hibernate the best choice?", and this lead me to ask the same question.

Although, I tend to use Hibernate as my first choice, it would be nice to see some head to head comparisons of Hibernate vs. TopLink (pros and cons), Hibernate vs. OpenJPA, Hibernate vs. Cayenne, etc. Searching around finds that many of the comparison are pretty old and not very detailed or compelling.

Having used other ORM frameworks, I found that when something goes wrong with Hibernate, you can usually google and find an answer, and there are many books on Hibernate. In my experience, the other frameworks seemed to be a less well-worn path and it is harder to find answers to even common problems. This is not to say that Hibernate is better, but that it is a lot more popular. In the end, I use Hibernate because my clients use it, if my clients switched to TopLink or OpenJPA, then I would use them as well.

So this begs the question, if Hibernate works for you, you just might have something else to do, like implementing a client solution that makes your client money, than to try several other ORM frameworks. How much time should someone spend learning a new ORM framework (new to them anyway)?

Don't get this wrong, trying out new ORM frameworks is fine. If there is a large IT/developer organization, and you have a certain selection criteria like integrating with legacy databases, conformance to JPA specification, ability to hire new developers, easy of use, etc. then by all means having someone create a few prototypes and/or proofs of concepts and try out a few ORM frameworks is great. There is often good ROI in this type of testing. Perhaps share your findings with the rest of us.

However, it seems if you are a vendor of a JPA solution, you could start by pointing out how your product differs from Hibernate. Like it or not, Hibernate dominates the mind-share of developers. If you can't prove your ORM frameworks has compelling reasons for switching, why should developers spend their time evaluating your product?

Now let me boil things down to brass tacks, it seems vendors of the ORMs should write white-papers, articles, blogs, and such to highlight the advantages of their ORM framework versus Hibernate. Logic dictates that if you have a product and there is a competing product that dominates the market that you might want to highlight what differentiates your product from the dominate one.

As a test, let's go to different vendor sites and see if they have comparisons of their ORM framework vs. the 800 pound gorilla, Hibernate.

So first let's go to Oracle TopLink website, you would expect since Hibernate has such a huge adoption rate in the industry that Oracle would want to point out why TopLink is better like a nice white-paper perhaps featured prominently on their TopLink site (see graph).

TopLink versus Hibernate

After hunting around a bit this entry appeared in the TopLink Essentials FAQ, Why should TopLink Essentials be used instead of JBoss(TM) Hibernate?

The two main points that seemed intriguing were as follows:

"Customers with any degree of complexity in the domain model or relational schemas, most notably where changing the schema is not an option, will benefit from the flexibility and proven nature of TopLink."

NOTE: At times mapping Hibernate to legacy systems can be challenging. How is TopLink better at this? Are there articles or white-papers, etc. that attempt to prove that TopLink is better at legacy integration? (I find that many developers are not aware of all of the features that Hibernate provides for legacy mapping.)

"As the reference implementation of JPA TopLink offers the first certified implementation of this new standard. as well as providing some useful value-add functionality. Going forward this open source project will continue to innovate based on contributions from Oracle, Sun, and others."

NOTE: This is compelling to me since I now use the JPA interface to Hibernate whenever I can.

Now I did not find the arguments in the FAQ particularly compelling or at all detailed. Sadly, you can find more compelling arguments in some of the TopLink public forums and random blogs. However, none so compelling that I feel the sudden need to switch.

Now on to the BEA site to look at dear KODO. I have always heard good things about KODO. Sadly, I found the BEA KODO site to be very out of date. It mentions a 2005 award for KODO as the lead news item. It also mentions that OpenJPA is in incubation, it has been out for a while. Even the FAQ, which did mention Hibernate, merely mentions that Hibernate is not EJB3 (seems it should say Hibernate is not JPA). This site really seems out of date and like the TopLink site mosty ignores the elephant in the room (see graph).

KODO vs. Hibernate

Well, let's look at the Apache OpenJPA site, as KODO's DNA may live at Apache long after Oracle decides on a single JPA solutions and likely leaves KODO to rot on the vine. Searching through the main site, FAQ, OpenJPA documentation, etc., I find no mention of Hibernate. Now this is an open source project so one would likely expect to see no marketing angle per se. But, you might expect that a project recognize that many would not be able to use this project without first justifying their pick against picking Hibernate (OpenJPA barely appears at all on job graphs). How many IT/development managers will feel comfortable with this choice without some explanation?

Now on to the next ORM framework site, Cayenne. No mention of Hibernate vs. Cayenne (but I know I have read articles on this). Seems like there might be some compelling ease-of-use arguments for Cayenne vs. Hibernate but they choose not to compare them. (Cayenne barely appears at all on job graphs)

Now back to Jonathan Lehr blog, Jonathan states that he feels TopLink and Cayenne are better choices than Hibernate and cites his reasons for these choices. There is a long discussion on the pros and cons of each in the comment section. I'd love to see more discussion, and I'd love to see some viable alternatives to Hibernate, but feel that no vendor or open source project does a real good job of pointing out the differences and possible limitations of Hibernate. If the vendors and project owners choose not to make their case, it makes it very difficult for the rank and file developers to make their case.

Perhaps one reason Hibernate is so dominate is because competing projects are so bad at technical marketing. Not one project I looked at mentions Hibernate on their front page. I could not find a decent comparison of features (to Hibernate's) on any of the ORM sites.

Has anyone done a comparison of Hibernate and OpenJPA, TopLink Essentials, Cayenne that compares ease-of-use, caching, tool support, legacy integration, etc.? Perhaps such an internal report was used to decide which ORM tool to pick. If so, what were the results?

If you use TopLink, OpenJPA, Cayenne instead of Hibernate, why?

Were you hoping that JPA would level the playing field and there would be more competition?

About the author

Rick Hightower is CTO of Mammatus and is an expert on Java and Cloud Computing. Rick is invovled in Java CDI advocacy and Java EE. CDI Implementations - Resin Candi - Seam Weld - Apache OpenWebBeans

Published at DZone with permission of its author, Rick Hightower.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Andrew McVeigh replied on Sun, 2008/02/24 - 7:33pm in response to: Mike Keith

(as an aside, i appreciate you not responding in kind to my message. my tone was getting quite heavy handed, and now i've had a rest from programming and drinking lots of coffee i'm back to normal... ;-)

Yes. the conformResults option is still there, and no, it is not slow or broken. In-memory queries are a means of optimizing a certain subset of queries and for those cases issuing the query in memory is going to be faster than making a round trip to the database.

seems similar to how it was back a few years ago, although we were advised not to use the facility due to speed concerns -- maybe this aspect has changed. I realise that it would need another query engine, or the same one retargeted at memory, but i consider it incomplete in its current form... i've used one JDO product that supports this fully out of the box -- without penalty. Admittedly, it is an object databases (my background).

Maybe it's just me, but anyone who just bashed a product based on a 5-year old version (during its most troubled times, I might add again) and said they "would never go down the ... route again" is not going to be "sincerely interested" in the product.

Not at all -- I *was* more than seriously interested in the product, i literally lived it for 5 years. I'm not your casual user with no history of this product. I used it full-time from '99 to 2004 and introduced it into several organisations. From the current docs, it looks like a lot of my knowledge is still useful. I presume it hasn't been completely rewritten in that time?

As for the "troubled times", consider the situation from the perspective of a user/buyer. They have no idea of the troubles (literally not told) and probably don't want to know. All I know is that my projects got locked into a product strategy that had serious flaws (at the time)... and as the lead architect of these projects, i got to feel the pain (mainly financial)...

Does this mean you have had a slight change of heart?

Well, no statement is ever absolute ;-) If i tried toplink again and it offered something better than I could get elsewhere, then of course i'd use it again, but only via a non-proprietary interface. Reading back, I've surprised myself with the intensity of my posts -- i still have a reasonable amount of anger about the way toplink has been managed historically. i realise that it's not your fault, or even your problem, but i can't rant at webgain as they no longer exist ;-)

At any rate these products take a long time to evaluate and fully understand. It was only 6 months into my first toplink project that I first discovered the reference/transactional issue. My solution at the time entailed using a session per unit of work, but while this allowed us to clean out the cache for transactional items on commit (no multithreading) it obviously has its flaws.

Certainly one area that toplink excelled at was the mapping workbench. Do you know is this is being open sourced?

Whether you use TopLink or Hibernate or any other implementation, using JPA just makes portability sense

I agree completely. Unfortunately this was not an option for us at the time as toplink didn't support another API.

Without customers using it or asking for it there was no reason for the JDO implementation branch to even continue.

Hmm. We certainly begged for a JDO interface, but again this was when it was with webgain. To be honest my earnest hope was that we could target JDO and get off the proprietary product train. Mail me if you are interested and i can discuss the details with you.



Doug Clarke replied on Sun, 2008/02/24 - 11:50pm


I was involved on what I believe was the engineering side of your experiences. It would be great to connect and discuss your issues at more depth. We have enhanced conforming query capability as well as offering customers the flexibility to use conforming or to flush to database using the solution that works best in their scenario. I'll drop you a note and we can discuss this offline in more detail. I believe you will find that our enhancements in the area of conforming as well as the changes made in the caching architecture align closely to what your team was looking for. We do take customer feedback seriously and work hard to address these requests.

 As far as the Workbench goes we have contributed it into the EclipseLink project and it should be available for general use in the next milestone build. Since JPA has obvious ties to annotations which are container within the source of your model we are also leading the Dali project at Eclipse developing the JPA tooling within the Eclipse IDE.



Mike Keith replied on Mon, 2008/02/25 - 10:37am in response to: Andrew McVeigh

Admittedly, it is an object databases (my background).

I also spent some years with ODB (in a not-yet-published e-panel that I did for InfoQ I compared them to the beta-max of the 20th century ;-) and there is no question that they can do some neat stuff in an OO environment. Unfortunately (as you undoubtedly know since you have obviously done some ORM yourself) they are not an option for a great many folks with legacy databases and also since they are not very accessible from non-OO environments. They are fun to work with, though (at least the good ones were -- the bad ones were sheer torture).

I *was* more than seriously interested in the product, i literally lived it for 5 years. I'm not your casual user with no history of this product. I used it full-time from '99 to 2004 and introduced it into several organisations. From the current docs, it looks like a lot of my knowledge is still useful. I presume it hasn't been completely rewritten in that time?

Okay. Sorry I seem to have misrepresented you, then. In that case you would be a very valuable person to provide input into the EclipseLink project if/when you ever need to do Java persistence again. The basic concepts and features have been retained, but with a whole new raft of features and options that people have asked for and that is expected in a modern ORM. For example, the regular shared object caching model is still common, but with a host of new options including class-based coordination in the cluster, eviction and invalidation policies, numerous change-tracking granularity options, etc.

Anyway, I understand that you had a bad experience with Webgain (so did I and I worked for the company!) and that you have some left-over frustration. Sorry you had that, and all I can do now is assure you that the new EclipseLink project is a very open project and offers a feature-rich runtime. I'm hoping you will get a chance to try it out and see for yourself. You might even decide to get involved as a committer :-) 


Jozef Hribik replied on Wed, 2008/03/19 - 10:14am in response to: Roman Pichlik

[quote=rp117107]iBatis is good solution for simply use cases ... [/quote]

I disagree. I was asked to take over 2 projects and rewrite the persistence layer to "something clear and easy to grasp". In both cases they had troubles with growing complexity of object relations. I presented and suggested to use iBatis. They agreed and are still very satisfied with iBatis.

2005 - switch from Frontier JDO to iBatis

2007 -  switch from JPA (Toplink) to iBatis

I would like to present one more benefit of iBatis. The first customer (in 2005) had very good Oracle gurus without Java knowledge. The co-operation was superb. They were able to optimize the SQL statements and directly change the iBatis XML mapping files.

replied on Tue, 2008/04/15 - 6:24am


Thank you for posing this question on "Is Hibernate the best choice for JPA?" Here are a few direct responses that we have on our website for CocoBase that you and others may benefit from.

The CocoBase Solution is specifically focused on being the best choice ORM platform for building JPA standard based development of enterprise applications. We do our best to communicate the differences between CocoBase and Hibernate. Here are three examples.

1. "CocoBase® Is Only JPA Platform To Provide Full Range Of Enterprise Features"


This document organizes ORM features by level of complexity from "simple desktop" to "complex external enterprise". It makes it easy to see all of what CocoBase covers in a somewhat simple manner which is very helpful to people. The basic conclusion of this document is that CocoBase is the only JPA provider to offer the full range of enterprise features with the full depth and flexibility needed at this level of development.

2) "CocoBase Is On Average 200% To 400% Faster Than Hibernate / OpenJPA / Toplink JPA"


A high performance / scalable platform with the required expertise to assist you to maximize this on most any hardware platform. The architecture of CocoBase permits a level of performance and efficiency for database operations that are not readily or easily accomplished without the CocoBase platform. This translates into direct business goals achieved, money saved, and requirements met.

Bottom Line Example: The CocoBase ORM platform performs and scales at a minimum of 200% to 400% over all other ORM JPA providers, and is 10 to 20 times faster than Toplink Essentials - their open source JPA implementation. In fact, CocoBase's real advantage here is in managing complex object models and retaining linear performance / scalability.

3. "CocoBase Delivers TOP TEN Enterprise Persistence Features For JPA Development Not Available From Other JPA Providers"


This document does a good job of helping people to see that CocoBase is distinct and different from other JPA Providers since these common and needed enterprise persistence features are only available in CocoBase.

I am always working on ways to create more exposure for CocoBase and appreciate all of your insights / responses to this question.

Now, I am asked from time to time what has been going on with CocoBase and where are you now?

The CocoBase technology was doing very well by responding with solutions for the industry standards of EJB 1 and EJB 2. As EJB 2 lost its lustre, we were waiting for an industry standard to emerge which came close with JDO, which we were intending to support in version 2.0 (that included ORM and did not require byte code manipulation). Then JDO appeared to get set aside with the release of EJB 3 and JPA. So we followed the industry and moved to support JPA. CocoBase is now a fully certified implementation of JPA.

During this time we very painstakingly re-wrote the entire user interface for version 5. The new GUI Workbench in v5 finally meets all of our internal requirements for an intuitive and easy to use interface.

From lots of experience and feedback we had identified that a key point of failure for ORM was the lack of an easy to use GUI that simplified the task specifically for the junior to intermediate level engineers. It appears from customer feedback that v5 gui workbench and wizards have eliminated as much of this as is possible. Our on-site training also directly addresses this point and is quite effective at reducing the learning curve to get up and running on the CocoBase platform.

We have included a lot of direct support for JPA in the gui as well. We are finding increased success with customers on the new gui and especially with JPA.

I hope my comment has added some good substance to this discussion. I wish everyone the best and perhaps there is some good competition to Hibernate around. :)

Warm Regards,

Greg Baker, Director of Sales & Marketing, Thought Inc.

Robin Bygrave replied on Wed, 2008/05/14 - 4:36am

Hi all,

This is an interesting thread... just to throw my 2c in...

What is missing for me in JPA and Hibernate is ...

1. Good dynamic (query language) support for "Partial Objects" for every node in the object graph (not just the top level node). As I see it JPQL will have to change in the future... watch this space.

2. AutoFetch support (although its a new idea... so hopefully they'll get around to it soon)

3. Large query support (Aka per object graph persistence context)

4. Lots of little things... like background fetching, better batching control etc.

The other "interesting" feature in Ebean relative to JPA and Hibernate is that it is architected to not require a session object - this is perhaps best described as having a "singleton" entityManager. This means there is no concept of attach/detach/merge/flush but rather just save() and delete() methods. IMO this makes Ebean much easier to understand and use.

So, for people wanting to see a different sort of ORM approach that still uses all the JPA Mapping annotations (@OneToMany etc) then they should check out Ebean at www.avaje.org

Cheers, Rob.

Adam Wozniak replied on Wed, 2008/05/28 - 5:13pm

I'm using Hibernate for 2-3 years and I really like it for its flexibility.

But there are some frustrating thinks

* lack of SQL union equivalent

* lack of Oracle hint support (I must fall back to native SQL to use Oracle hints)


Kind regards,


Mike Keith replied on Wed, 2008/05/28 - 5:42pm in response to: Adam Wozniak

[quote=Adaslaw] I'm using Hibernate for 2-3 years and I really like it for its flexibility.

But there are some frustrating thinks

* lack of SQL union equivalent

* lack of Oracle hint support (I must fall back to native SQL to use Oracle hints)


Anybody that wants to use Oracle database features should really be using TopLink, which has additional support for the Oracle database, including Oracle hints, stored procs, spatial, temporal queries, VPD, etc.  

ishtiak sk replied on Sun, 2009/01/04 - 12:38am

I am real fan of Hibernate and I have several blog / personal pages at

<a href="http://hibernate-questions.weebly.com">http://hibernate-questions.weebly.com</a> 


In free times, Can anyone visit and comment to improve these pages?





Anthony Berglas replied on Mon, 2009/03/09 - 2:03am

http://www.SimpleOrm.org certaily has a clear rational as to why it is better than Hibernate et al.

"SimpleORM provides similar functionality to Hibernate by mapping data in a relational database to Java objects in memory. Queries can be specified in terms of Java objects, object identity is aligned with database keys, relationships between objects are maintained and modified objects are automatically flushed to the database with optimistic locks.

"But unlike Hibernate, SimpleORM uses a very simple object structure and architecture that avoids the need for complex parsing, byte code processing etc. SimpleORM is small and transparent, packaged in two jars of just 79K and 52K in size, with only one small and optional dependency (Slf4j). (Hibernate is over 2400K plus about 2000K of dependent Jars.) This makes SimpleORM easy to understand and so greatly reduces technical risk.

"SimpleORM version 3.* is a major upgrade that provides a distinct DataSet component while simplifying record definitions. See the SimpleORM White Paper for a full description of how SimpleORM works."

Love it or hate it it certainly is not simply Yet Another ORM.


Dan Cristoff replied on Tue, 2011/03/08 - 6:17pm

TopLink Essentials is nice and easy but i don't know wich is the best,i guess the new releases are better.Adidasi

Patrick Dezenzio replied on Fri, 2011/05/20 - 4:19pm

I know this thread is outdated but I thought to add my thoughts 3 years later:-) We have a J2EE banking application consisting of 80 EJBs and nearly 3100 Java classes. It's a huge system. We have a 100% Oracle solution from OC4J to TopLink. Here's where I think Oracle loses - cost. Because OC4J is sunsetted, we are forced to buy into BEA which is 6 figures every year. Then add TopLink and 11g and you can see where I'm going. We are looking at converting from Oracle (except for 11g) to JBoss and maybe Hibernate. The cost savings is equal to 3 salaries a year. For a medium-size shop (roughly 25 Million in revenue) with nearly 100 employees, going to JBoss and Hibernate seems the best path. Also, where's the documentation? Oracle makes it impossible to search answers on their fourms. JBoss and Hibernate have tons of support and we plan to get the paid JBoss support because simply we get better feedback from them. With Oracle, not once in 4 years have they ever attempted to call us to check up on us.

Jan Kowalski replied on Sat, 2011/05/21 - 6:26am

Hi, I created performance test beetween jdbc and hibernate, and you can find it here http://phpdao.com/hibernate_vs_jdbc/

Ash Mughal replied on Thu, 2012/01/26 - 2:12am

Is JPA there yet? I ask this for all the 'hibernate, hibernate, hibernate' people, particularly as Gavin King has been on the JPA architecture group. We used EJB 3.0 a couple of years ago on JBoss. There were some limitations to the JPA 1.0 API, such as criteria support. (Added to JPA 2.x I believe) But as someone who's used JPA but not the hibernate API directly, I'd ask why not use hibernate through a neutral API and swap in another such as toplink as needed?

advanced java

Christophe Blin replied on Thu, 2012/04/26 - 6:22am

I'm impressed by the fact that EVERY post about ORM leads to the SAME flame war with the SAME arguments.

#1 I do not need an ORM

#2 my ORM is better than yours because I can blablabla

#3 what, you are still using a RDBMS ? please switch to NoSQL


So please, be real engineers and choose the tool that matches your needs (and do not complain about the tool if you did a bad choice ;) ) !


Kookee Gacho replied on Mon, 2012/07/02 - 7:09am

Although often associated with cold temperatures, the root purpose of hibernation is to conserve food during a period when sufficient food is scarce. It is the animal's slowed metabolic rate which leads to a reduction in body temperature and not the other way around.-Arthur van der Vant

Gym Prathap replied on Fri, 2013/06/28 - 9:26am

EclipseLink and OpenJPA are the major competitors for Hibernate

Java Training in chennai 

Nagaraj Lm replied on Mon, 2013/12/09 - 1:24am

Ohh my God...i am still a middle level developer...there mnay conversiontaions were confusing...Can u tell in one world...IS hibernate better? Yes/No?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.