What's the difference between Spring Data MongoDB and Hibernate OGM for MongoDB?

Disclaimer: I am the lead of the Spring Data project, so I'll mostly cover the Spring Data side of things here:

I think the core distinction between the two projects ist that the Hibernate OGM team chose to center their efforts around the JPA while the Spring Data team explicitly did not. The reasons are as follows:

• JPA is an inherently relational API. The first two sentences of the spec state, that it's an API for object-relational mapping. This is also embodied in core themes of the API: it talks about tables, columns, joins, transactions. Concepts that are not necessarily transferable into the NoSQL world.
• You usually choose a NoSQL store because of it's special traits (e.g. geo-spatial queries on MongoDB, being able to execute graph traversals for Neo4j). None of them are (and will be) available in JPA, hence you'll need to provide proprietary extensions anyway.
• Even worse, JPA features concepts that will simply guide users into wrong directions if they assume them to work on a NoSQL store like they were defined in JPA: how should a transaction rollback be implemented reasonably on top of a MongoDB?

So with Spring Data we chose to rather provide a consistent programming model for the supported stores but not try to force everything into a single over-abstracting API: you get the well-known template implementations, you get the repository abstraction, which works identical for all stores but let's you leverage store specific features and concepts.

Disclaimer: I'm one of the Hibernate OGM developers so I'll try to provide some of the reasons behind it.

Hibernate OGM provides Java Persistence (JPA) support for NoSQL solutions. It reuses Hibernate ORM’s engine but persists entities into a NoSQL datastore instead of a relational database. It also aims to provide access to specific datastore features when JPA does not have a good fit.

This approach is interesting for several reasons:

• Known semantic and APIs. Java developers are already familiar with JPA, this means that one won't have to learn lower level API. It also supports both HQL and native backend-queries.

• Late backend choice. Choosing the right NoSQL datastore is not trivial. With Hibernate OGM you won't have to commit to a specific NoSQL solution and you will be able to switch and tests different backends easily.

• Existing tools and libraries. JPA and Hibernate ORM have been around for a while and you will be able to reuse libraries and tools that uses them underneath.

• Most of JPA logical model fits. An example of a good fit is @Embedded, @EmbeddedCollection and @Entity (that can be a node, document or cache based on the datastore of choice). Admittedly, annotation names might be strange because you will also have to deal with @Table and @Column.

• JPA abstracts persistence at the object level, leaving room for a lot of tricks and optimizations. We have several ideas planned, like polyglot persistence: storing data in several data stores and use the best one for a specific read job.

The main drawback is that some of the concepts of JPA are not easily mapped to the NoSQL world: transactions for example. While you will have access to transaction demarcation methods, you won't be able to rollback on data stores that don't support transactions natively (transactions, in this case, will be used to group operations and try to optimize the number of calls to the db).

Also, if your dataset is by nature non domain model centric, then Hibernate OGM is not for you.