Hibernate, just stop it!

In 2001 Hibernate was created to ease development for the hordes of unhappy developers fighting with Java’s poor EJB implementation. EJB was so confusing and over-engineered that Hibernate’s simpler approach seemed like pure heaven in contrast.

Eventually hibernate inspired Java’s JPA and became a certified implementation of JPA.

History lesson is over.

Lets look at the status today. Right now Hibernate is a very popular ORM java library, maybe the most popular of them all. And I can’t understand what is wrong with people.

Hibernate promises to simplify database access, it maps your objects to a database schema and is database agnostic.You connect to any relational database you want, annotate your classes and variables, and Hibernate does all the magic. No SQL! Magic! Magic I tell you!!

I have tried using Hibernate for several projects. Every time, using Hibernate has been ok until at some point I start using many-to-many relationships, or want control over the order of things to be loaded. I start fiddling with the annotations, lazy loading, try HQL, and start getting pissed off. Then I look at what sql queries are being sent to the database, and it hits me every time:

As soon as a project gets to a certain size Hibernate’s magic ends up getting in the way.

I most often know how I want the database to be, and I know SQL enough to get the results I want. If I want to tune queries or write queries, then SQL is the bloody language for it. Not HQL or any other ORM bastardized substitute. What is wrong with using the query language created for this purpose?

Hibernate is useful for newbie developers that are scared of SQL and just want it to go away, while they riddle their class files with annotations, and let Hibernate automatically generate a database and puke endless sql queries over it.

Those developers should grow up and start asking themselves why they are using a library that mangles their understanding of how databases work, messes up the classes with annotations, and has a tendency to need tuning to get the number of queries and performance to an acceptable level once your project goes beyond crazy simple.

Am I missing something here, or is it stupid to have to tune the library that is supposed to simplify your database access, so that it isn’t interfering with your programs access to the underlying database?

I agree that using JDBC directly is a hassle. Having to do all the setup, handle connections, make sure you call rollback when an exception occurs in a transaction, do your own caching and so on… it can get tedious.

A friend and colleague of mine (Lars Aaberg) has the same opinion as me, and actually did something about it. Instead of using a monster ORM solution, he made his own library, called Sql2o  that helps with connection handling, transaction handling and batching, and then gets right out of the way.

Sql2o supports method chaining which can be nice for readability, and can automatically map tables to classes (using reflection) for simplicity. Sql2o is not an ORM, and it does not do any table or query generation for you. You have to make your database, and you have to write the sql queries to manipulate the data, but Sql2o helps with the rest and removes most of the JDBC boilerplate code that you normally end up having to write.

So now I get the best of both worlds. I have full control of the database and queries, and don’t have to write tons of boilerplate code to get things done. Combine that with using Play Framework and its built in caching, asynchronus job execution, and suddenly web application development with Java is pure joy.

Now go and remove Hibernate from your project, and start getting control over your database and queries! It will save you a lot of annotation fiddling and you will thank yourself a few years down the road when you have a better understanding of databases, and see some other developer swearing at his Hibernate-dependent project.


PS! If you are still not convinced, then have a look at this great video from Christin Gorman’s lightening talk titled “Hibernate should be to programmers what cake mixes are to bakers: beneath their dignity”.


28 Responses to “Hibernate, just stop it!”

  • Alfredo Zuloaga Says:

    I thought you don’t use all the power of hibernate like cache or JPA, if you don’t like Hibernate you give a try to Ibatis or Spring SQL as good alternatives to hibernate they give you all power of SQL that you project needs.

  • Richard Vowles Says:

    or even ebean which gives you both sql and orm and has been around for years.

  • Ricki Sickenger Says:

    Thanks for the comment!

    ebean looks like a nice alternative, although I am not really that interested in the ORM capabilities. I just want something that simplifies the handling of connections, transactions and batching, so I get to use sql, without the boilerplate code that jdbc requires. :-)

  • Ricki Sickenger Says:

    Alfredo: Thanks for the comment!

    My problem with Hibernate is the way it fools people into thinking that complex database issues are object-relational problems. Hibernate, JPA and a lot of other ORM’s keep you thinking about the objects and not the database, but that abstraction falls apart as soon as you have to tweak for performance issues. :)

  • Michael Krog Says:

    If pure SQL queries are wanted, then Spring JdbcTemplate is really nice:

  • Paul Zepernick Says:

    Why not just use the Hibernate SQLQuery class when you want to execute raw SQL, and you can even have hibernate bind it back to your model? That is what I have done in the past instead of trying to create a complicated query with HQL.

    Hibernate really excels at doing CRUD work. I agree anything complex should just be handled through straight SQL.

  • Ricki Sickenger Says:

    Hi, thanks for the comment.

    Regarding just using SQLQuery class and using the Hibernate binding, I feel that any project other than a simple throwaway thing usually ends up with one-to-many or many-to-many relations and propagating changes. This is when conforming to Hibernates way of thinking gets just as difficult or worse than just working with the database directly.

    That is my humble opinion 😉

  • Richard Vowles Says:

    My comment with using Ebean (which is default on Play2 Java) is that it treats SQL as a first class citizen, allowing you to swap back and forth between the two easily.

    Its documentation specifically says “SQL is much better for a whole lot of stuff, you should just use it”. It lets you use it directly, load partial data back into an entity model and then spelunk from there, it has a fluid API and does instrumentation to keep fast. It also does auto-tuning of your queries if you aren’t use SQL which is crazy cool.

  • Ashwini Says:

    I am glad someone wrote this! Thanks :)

  • Devanshu Says:

    Absolutely True!!! I agree 1000% with you. I mean look at the code annotations annotations annotations…everywhere. It looks so nasty and complicated with all those hibernate code…

    There is so much automation in Java code generation for hibernate that virtually everything is being generated through tools…. Although there already exists but why can’t these open source guys focus on designing an extensive gui based query builders to generate the most complicated queries.

    Hibernate is over hyped.

  • Rakesh Waghela Says:

    Nice catch on hibernate, one open source project which has impressed a lot of guys in java community is http://www.jooq.org

    Type Safe SQL In Java ! Give it a try as an Hibernate Alternative !

  • Kapil Says:

    This is how I typically break it down.

    Use ORM to map my object to DB model. Use the ORM for the basics
    – Create
    – Update
    – Delete
    – Simple Read by PK or UK.

    For all other finders I use my own SQL. My last implementation I used JPA with Eclipse Link and have been happy with it.

    I am about to start playing with EBean soon. Curious to see the experience others have had with EBean.

  • Lukas Eder Says:

    You might enjoy visiting http://www.no-more-hibernate.com

    Although Hibernate (and ORMs in general) surely have their place, as sometimes, “magic” is good enough, SQL should really be put back into Java as a first-class citizen.

  • Mladen Adamovic Says:

    I’ve seen many projects which have bad performance and did use Hibernate or JDO. I hate those technologies (along with JPA).

    After writing thousands of line of JDBC code I’ve realized how it could be done properly.

    After analyzing dozens of hibernate alternatives, I couldn’t find the one I liked.

    Finally I made fast java ORM framework and open sourced it at:
    It is quite similar to ActiveJDBC, but I like mine more.

    Hope someone might like it.

  • Tarek Says:

    I agree that new frameworks are available that do a better job and are simpler to use than Hibernate and JPA. I recommend studying and using the one that fits your needs better (I’m using Ebean’s Play! Framework implementation, I really like the ActiveRecord pattern).

    But I disagree when you say Hibernate is not suited for big applications. It’s just that Hibernate focuses on Objects. In order to successfully work with Hibernate, one has do design the database around the objects, not the other way around. We are used to think of database entities and creating the objects to manipulate them in Java.

    I’m not saying this is bad design, it’s just different (and modern frameworks allow that).

    When it came out, Hibernate was great because it cut down a lot of the work that had to be done manually (as you said, there weren’t a lot of frameworks that did it well).

    The SQL abstraction allowed switching the database providers without rewriting queries, in a time where SaaS, SOA and cloud applications were still crawling (so you had to write your application to work with whatever database the clients had a license for).

    Due to its focus on Objects, things that are normal in SQL, such as partial column selections (select firstname, lastname from users), are a nightmare to do with Hibernate (using projections and transformers).

  • Sachin Says:

    I hope one day these so called S/W Architects understand this….programmers have a tendency to insert hibernate wherever they see a database.. :)

  • gaius gracchus Says:

    AMEN, Brother!!!
    This whole movement that thinks “SQL is evil” is just baffling.
    The optimizer code for most modern databases is some of the most sophisticated code on the planet. Why spend a bunch of money on your database engine and then hobble it completely?

    My view of Hibernate and enterprise level relational database engines is this:
    Picture a huge, lumbering semi or tow truck dragging your Lamborghini behind.

    There you have it.

  • john Says:

    You talk a lot of sh*t about Hibernate without saying anything about how much experience you have using it and other similar tools. It’s hard to take anything you say seriously given that I have no idea whether you picked it up once and then just looked around for other people’s opinions and reworded them or if this is based on solid experience and lessons learned personally. This is coming from someone who already doesn’t like Hibernate, so it’s not like I’m in love with it and just looking for reasons not to trust your article.

  • Eric Says:

    John, I wrote an ORM back in the days when there was no such thing. So I know ORMs. I talk shit about Hibernate because Hibernate is shit. I know it’s shit because I’ve written software that does the same stuff Hibernate does, except without the brain damage.

    How bad is Hibernate? Let me list the ways…

    * Hibernate caching often *slows down* your program.
    * Hibernate session flush is ridiculously, ludicrously slow. As in, takes a full minute to flush a session that has a mere 30,000 objects in it. I ask on the Hibernate mailing list why it is so stupidly slow, they reply “well, it’s n squared problem, because we have to check for dependencies between each of the objects in the Hibernate session.” Oh. Really. So. Uhm, I know what the dependencies are between my objects. I don’t need Hibernate to know them. I just need Hibernate to flush my objects in the order in which they were frickin’ created, because that’s the order they need to be in, else I wouldn’t have created them in that order! Hibernate is *FULL* of little helpful things like that, which brings the other thing to a head…
    * Modern web sites are comprised of dozens of web servers talking to a database back end. Hibernate’s mechanisms for making sure that two sessions on different servers don’t modify the same object are full of fail. They throw spurious exceptions instead of doing something reasonable, and otherwise cause your program to collapse rather than do what’s expected.
    * And then of course, Hibernate’s performance as a whole sucks donkey dung. For example, if I want to do a join to get all the attributes of an item, Hibernate doesn’t let me go fetch just the attributes I need. Oh no. It’s none, or all! It’s either full-on lazy prefetch-nothing causing thousands of tiny queries to be issued, or so aggressive that it’ll fetch the entire database into memory and blow up my servers!

    Frankly, I’ve spent more time fighting Hibernate into doing what I need than I would have spent just using iBatis or something similar to write SQL.

    My final thought is that Hibernate is fine for toy web sites that see a few dozen users per day. But once you hit production and you’re talking web sites that see hundreds of thousands (or more) users per day, Hibernate sucks so bad that nobody — NOBODY — who makes real production web sites that serve millions users per day uses it. Nobody. Not Google. Not Facebook. Not Twitter. Not Amazon. Nada nobody zilch zero. Maybe if you don’t intend to grow your company into being the next big thing, you can live with Hibernate’s pathetic performance. But once you hit that scale, you’re not talking SQL anyhow — nevermind a ridiculously slow and clunky thing like Hibernate on top of SQL, which is like taking a Yugo and yanking off three sparkplug wires. It might run. But if it does, it’ll run so bloody slow as to be useless.

  • Michael Belivanakis Says:

    Hello, Ricki! I remember back in the mid-00s when hibernate was the rage you were interested in it, alas, the project we were working on at that time did not call for it.

    (My goodness, can you believe it has been 10 years!?)

    I have also used Hibernate since then, and I have come to similar conclusions as you: too much effort trying to figure out why it does what it does; too much effort trying to get it to do what you want it to do instead; too much magic behind the scenes; lack of error messages to tell you what is wrong; and so on. (And did I mention the horrendously long start up times?)

    When the magic works as it is supposed to, everything’s zen. But when the magic does not work, it is hell.

    I think that the problem with Hibernate lies in the fact that it tries to do so much, that it does not do anything well. It can supposedly be used for taking an existing database schema which was designed without having ORM in mind, and build ORM on top of it; and it can supposedly also be used for taking class hierarchies which were designed without ORM in mind, and add an RDBMS underneath them; these are quite high aspirations, but they cannot possibly work for any non-trivial design, and the fact that hibernate tries to support these features makes it immensely complicated and clunky.

    What I am *not* convinced about though, is the necessity of SQL. I think there should be a way to treat the RDBMS simply as a persistence medium for an objectspace and therefore to not have to directly deal with the RDBMS (or RDBMS-related notions) at all. And mind you, I am saying this even though I am well versed with SQL and I do not have any problem using it.

  • eugen Says:

    Interesting. A friend of yours wrote his own library to replace hibernate. So cool !.
    Let’s reinvent the wheel for every project or company.
    The advantage of hibernate is that it is providing decent performance for 90% of the projects and it is reducing the amount of time spent in the DAO layer.
    You cannot add value to a project if you write your own ORM every time….

  • Paul Irvine Says:

    Good discussion and I’m glad to see that more developers are coming to the same realization that ORM’s are just one more tier to get in the way. Using SQL is really easy, and give me a developer who understands the domain business model first, and I’ll take them over anyone who is looking for a magic bullet with an ORM especially hibernate.
    in the simplest case, you can generate restful services for the all the crud operations you need. And the very concept of allowing hibernate to do joins is totally baffling to me… the database should do the joins! its what its built to do, with zero network latency and a very specialized optimizer built especially for the purpose of that specific flavor of database. Depending on a developers optimization hints at a generic layer, for non-specific dbms vendors, in the app server (with latency to the db), is madness. ORM’s were yet another dumb ‘left turn’ the software industry took in the 2,000s. And agree with you entirely Rikki – any business application is always going to have many-to-many’s … if it doesnt, your db model is almost certainly wrong. Has everyone really forgotten how to do logical and physical database design? Or are we still in the dark ages where the database was just somewhere for web developers to ‘stuff’ their objects? :) Cheers, and thanks for having the nerve to stand up and say that just because thousands are doing doesn’t make it “right”!

  • Ranjesh C Says:

    Very nice article. I’m able to relate completely to what the author is saying. From my knowledge Spring JDBCTemplate or any other ORM that uses SQLs is way more flexible without constraints and henceforth, reduces development effort and improves application performance.

  • There is no Such Thing as Object-Relational Impedance Mismatch | Java, SQL and jOOQ. Says:

    […] their “obvious” impedance mismatch with the relational world. N+1, inefficient queries, library complexity, leaky abstractions, all sorts of buzzwords have been employed to dismiss ORMs – often […]

  • mike huang Says:

    I couldn’t agree more. I always prefer apache dbutil over any ORM implementation.

  • Anonymous Says:

    You clearly missed the point of an ORM. An ORM isin’t meant to fulfill general query needs, it’s meant to hydrate domain objects in order to process commands, not queries… COMMANDS! If you are using the Transaction Script pattern for your domain model then you probably do not need an ORM at all, but with a rich object model how do you expect to hydrate complex object graphs and perform dirty checking to save them back? Running your own custom ORM solution would be silly…

  • There is no Such Thing as Object-Relational Impedance Mismatch | Evil Zone Groups Says:

    […] for their “obvious” impedance mismatch with the relational world. N+1, inefficient queries, library complexity, leaky abstractions, all sorts of buzzwords have been employed to dismiss ORMs – often containing […]

Leave a Reply