免責事項：私はSpring Dataプロジェクトのリーダーなので、ここでは主にSpring Dataの側面について説明します：
2つのプロジェクトの主な違いは、Hibernate OGMチームがJPAを中心に作業を行うことを選択したのに対し、SpringDataチームは明示的に選択しなかったことです。理由は次のとおりです。
- JPAは本質的にリレーショナルAPIです。仕様の最初の2つの文は、オブジェクトリレーショナルマッピング用のAPIであると述べています。これは、APIのコアテーマでも具体化されています。つまり、テーブル、列、結合、トランザクションについて説明します。必ずしもNoSQLの世界に移行できるとは限らない概念。
- 通常、NoSQLストアを選択するのは、その特殊な特性（たとえば、MongoDBでの地理空間クエリ、Neo4jのグラフ走査を実行できる）のためです。それらはいずれもJPAで利用できない（そして利用できるようになる）ので、とにかく独自の拡張機能を提供する必要があります。
- さらに悪いことに、JPAは、JPAで定義されているようにユーザーがNoSQLストアで作業していると想定した場合に、ユーザーを間違った方向に導くという概念を備えています。トランザクションのロールバックをMongoDB上で合理的に実装する必要がありますか？
そのため、Spring Dataでは、一貫性のあるプログラミングモデルを提供することを選択しました。 サポートされているストアの場合、すべてを単一の過度に抽象化するAPIに強制しようとはしません。よく知られているテンプレートの実装を取得し、リポジトリの抽象化を取得します。これはすべてのストアで同じように機能しますが、ストア固有の機能と概念を活用できます。