This is a pretty exciting moment, the first public alpha release of a brand new project: Hibernate OGM. Hibernate OGM stands for Object Grid Mapping and its goal is to offer a full-fledged JPA engine storing data into NoSQL stores. This is a rather long blog entry so I've split it into distinct sections from goals to technical detail to future.

Note that I say it's the first public alpha because the JBoss World Keynote 2011 was powered by Hibernate OGM Alpha 1. Yes it was 100% live and nothing was faked, No it did not crash :) Sanne explained in more detail how we used Hibernate OGM in the demo. This blog entry is about Hibernate OGM itself and how it works.

Why Hibernate OGM

One of the objectives of the Infinispan team is to offer a higher level API for object manipulation. One thing leading to another, we have experimented with JPA and Hibernate Core's engine to see if this could fit the bill: looks like it does. The vision has quickly expanded though and Hibernate OGM is now an independent project aiming to offer JPA on top of other NoSQL stores too.

At JBoss, we strongly believe that provided tools become available, developers, applications and whole corporations will exploit new data usage patterns and create value out of it. We want to speed up this adoption / experimentation and bring it to the masses. NoSQL is like sex for teenagers: everybody is talking about it but few have actually gone for it. It's not really surprising, NoSQL solutions are inherently complex, extremely diverse and come with quite different strengths and weaknesses: going for it implies a huge investment (in time if not money). (One of) JBoss's goal is to help lower the barrier of entry and Hibernate OGM is right inline with this idea.

We want to simplify the programmatic model of various NoSQL approaches by offering a familiar one to many Java developers: JPA. The good thing about a familiar and common programmatic model is that it's easy to try out one data backend and move to another down the road without affecting dramatically the application design.

So when should you use Hibernate OGM? We are not claiming (that would be foolish) that all NoSQL use cases can and will be addressed by JPA and Hibernate OGM. However, if you build a domain model centric application, this will be a useful tool for you. We will also expand Hibernate OGM feature set and use cases to address different areas (like fronting a RDBMS with a NoSQL store). Besides, Hibernate OGM is not an all or nothing tool. You can very well use it for some of the datastore interactions and fall back to your datastore native API for more advanced features or custom query mechanism. No lock-in here.

How does it work

Basically, we are reusing the very mature Hibernate Core engine and trick it into storing data into a grid :) We plug into Hibernate Core via two main contracts named Loader and Persister. As you could expect, these load and persist/update/delete entities and collections.

Early in the project, we have decided to keep as much of the goodies of the relational model as possible:

  • store entities as tuples
  • keep the notion of primary key and foreign key (foreign keys violation are not enforced though - yet)
  • keep an (optional) indirection layer between the application data model and the datastore data model
  • limit ourselves to core data types to maximize portability

Entities are stored as tuples which essentially is a Map<String,Object> where the key is the column name and the value is the column value. In most cases, the property is mapped to a column but this can be de-correlated (@Column). An entity tuple is accessible via a single key lookup. Associations as a bit trickier because unlike RDBMs, many NoSQL stores and Grid specifically do not have build-in query engines and thus cannot query for associated data easily. Hibernate OGM stores navigational information to go from a given entity to its association information. This is achieved by a single key lookup. The drawback here is that writing requires several key lookup / update operations.

Here is a schema representing the object model, the relational model and finally how data is stored in the data grid.

All this means that we do not store entity objects in the grid but rather a dehydrated version of them. And this is a good thing. Blindly serializing entities would have led to many issues including:

  • When entities are pointing to other entities, are you storing the whole graph?
  • How do you guarantee object identity or even consistency amongst duplicated objects?
  • What happens in case of class schema change?
  • How do you query your data?
  • How to replicate class definitions to other nodes?

Unless you store relatively simple and short lived data, never go for blind serialization. Hibernate OGM does this smart dehydration for you.

For more information on how we did things, please have a look at the architecture section of Hibernate OGM's reference documentation.

What is supported today and what about tomorrow?

Today Hibernate OGM is quite stable for everything CRUD (Create, Read, Update, Delete) and of course extremely stable for all the JPA object lifecycle rules as we simply reuse Hibernate Core's engine. Here is an excerpt on the things supported but for the full detail, please go check the reference documentation that list what is not supported.

  • CRUD operations for entities
  • properties with simple (JDK) types
  • embeddable objects
  • entity hierarchy
  • identifier generators (TABLE and all in-memory based generators today)
  • optimistic locking
  • @ManyToOne, @OneToOne, @OneToMany and @ManyToMany associations
  • bi-directional associations
  • Set, List and Map support for collections
  • most Hibernate native APIs (like Session) and JPA APIs (like EntityManager)
  • same bootstrap model found in JPA or Hibernate Core: in JPA, set <provider> to org.hibernate.ogm.jpa.HibernateOgmPersistence and you're good to go

Since Hibernate OGM is a JPA implementation, you simply configure and use it like you would use Hibernate Core and you map your entities with the JPA annotations. Same thing, nothing new here. Check our the getting started section in our reference documentation.

What we do not support today is JP-QL. Support for simple-ish queries is due very soon and will be based on Hibernate Search indexing and querying capabilities. However, you can already use Hibernate Search directly with Hibernate OGM. You can even store your index in Infinispan, in Voldemort or in Cassandra (and others).

Also, the NoSQL solution initially supported is Infinispan. The reasons behind it are quite simple:

  • we had to start with one
  • key/value is a simple model
  • we can kick some JBoss employees in the nuts if we find a bug or need a feature
  • we have a very good in-house knowledge about Infinispan's isolation and transaction model and it happens to be quite close to the relational model

That being said, we do intend to support other NoSQL engines especially other key/value engines very soon. We have some abstractions in place already so they do need polishing. If you know a NoSQL solution and want to write a dialect for Hibernate OGM, please come talk to us and contribute.


We are at the very beginning of the project and the future is literally being shaped. Here are a few thing we have in plan:

  • support for other key/value pair systems
  • support for other NoSQL engine
  • declarative denormalization: we have focused on feature so far, performance check and association denormalization is planned)
  • support for complex JP-QL queries including to-many joins and aggregation
  • fronting existing JPA applications

This is a community driven effort, if one of these areas interest you or if you have other ideas, let us know!

How to download and come contribute!

You can download the jars on's Maven repository or of course download the distribution (I'd recommend you download the distribution as it contains a consistent documentation with the release you wish to use).

Speaking of documentation, we tried to initially release with a fairly advanced reference documentation. In particular, the getting started and the architecture sections are quite complete: check it out.

Last but not least, Hibernate OGM is in its infancy, if you're interested in contributing or have ideas on how things should be done, let us know and speak up!

Many thanks to the team, to external contributors as well as the Cloud-TM project members for their support and tests.

Emmanuel and the team.

17. Jun 2011, 15:54 CET | Link
NoSQL is like sex for teenagers

ROFL! Well put. Great article, BTW.

- Manik

17. Jun 2011, 17:09 CET | Link

When are you going to support MongoDB

Was there any reason you chose
1) Voldemort or
2) Cassandra ?

17. Jun 2011, 17:42 CET | Link

Hi Anjan

We don't have a fixed schedule for alternative NoSQL support but if a community member steps up to help build the dialect and refine the abstractions, that will definitely speed up the process.

The reason we mentioned Voldemort and Cassandra is because they do offer a Lucene Directory ie a way to store the Lucene index in the datastore (instead of outside). Besides, Voldemort reuses the same design that Sanne has pioneered in Infinispan AFAIR.

20. Jun 2011, 11:38 CET | Link

What about performance and scalability? After all, those are the main reasons behind most NoSQL uses cases. I haven't seen anything in the documentation. Have some data?

Also, and directly related to the first question, do you plan to provide functionality to execute code directly on the data stores, like BigTable using a MapReduce approach.


20. Jun 2011, 17:16 CET | Link

H Charlie,

We have not yet worked on serious performance measurements (ie the overhead atop raw Infinispan usage) but that will come in time. The perfs I've done show that mass object graph creation is similar between Hibernate Core + H2 and Hibernate OGM + Infinispan. The big difference is that in Infinispan's case you can add more node.

Anyways the idea is to lower Hibernate OGM's overhead compared to raw NoSQL calls (for the same operation). The one that will be the hardest to match are low latency data grids like Infinispan and the like. Associations will add overhead of course due to their structure. But essentially, the performance and scalability model of Hibernate OGM should be bound to the performance and scalability model of the underlying NoSQL. We don't do that much magic.

To answer access to native functionalities of the underlying datastore:

  • we will make the data structure part of the contract so you can access your NoSQL store with its native APIs and play with the data stored by Hibernate OGM
  • we plan to support a Map / Reduce contract at some point, if nothing else to be able to efficiently implement build operations. We will see how JSR 347 goes and whether or not it tries to standardize such contract.

Hope that answers your questions. But again, this is early in the project, so everything is possible and it's not hard for people to make things happen :)

22. Jun 2011, 08:38 CET | Link
Hi Emmanuel,

Document database like mongodb have a readable representation of entities association.

Will Hibernate ogm use this representation if mongodb is implemented ?
12. Jul 2011, 12:58 CET | Link

Nice initiative.

13. Jul 2011, 12:55 CET | Link
What a superb blend of using Hibernate with NoSQL prehaps their will be more intiative of this sort .......
24. Jul 2011, 10:29 CET | Link
Alp Sehic | alpsehic(AT)
...a full-fledged JPA engine storing data into NoSQL stores...

Not directly through Hibernate, but why not JDO instead of JPA? I think JDO is the right place for the implementation...

29. Jul 2011, 22:07 CET | Link

I think Hibernate should focus on fixing bugs instead of extending functionality.

04. Aug 2011, 00:42 CET | Link

I think it should focus on both ;-) Stagnation would make it a dinosaur tech. And I am sure that with, a Hibernate with all annoying bugs fixed will be shipped.

02. May 2012, 18:04 CET | Link

This is a cool idea, hopefully will enable many of the JPA-based UI frameworks to operate on NoSql.

I see you started with the Hibernate core. Does that include transaction events, including BeforeTransactionCompletionProcess?

20. Sep 2014, 07:07 CET | Link

L'usage du tarot fait partie intégrante du monde de la voyance. voyance telephone

02. Oct 2014, 13:31 CET | Link

Better yet, this product ships in a discreet package – no one will ever know what’s inside! (That is, until your significant other sees that massive erection of yours! sparxx rx

24. Oct 2014, 00:06 CET | Link

I'm happy to be familiar accompanying your advice therefore I typically syntax treatises at inscription writing a essay moreover many my patrons are happy. Definitely, I won't restrain doing this because I contribute litter persons to deliver their age. Consequently they are satisfied by their scholars' vivacity.

25. Nov 2014, 09:17 CET | Link

I should say that you have done a great job and your writing style is awesome. Medical Entrance

29. Nov 2014, 15:16 CET | Link
godaddy renewal
29. Nov 2014, 15:16 CET | Link
hostgator coupon
01. Dec 2014, 05:35 CET | Link
10. Dec 2014, 09:41 CET | Link
Kailey | polo(AT) HELP for text formatting instructions. Then edit this text and check the preview.