Sob uma dimensão, com o passar do tempo, foi se percebendo que o acoplamento das aplicações escritas em linguagem de programação Java estava um pouco além da questão relativa a, simplesmente, conexão. As queries (selects, inserts, updates, deletes, dentre outras) escritas dentro do código ainda impediam que os SGBDs pudessem ser trocados de um modo fácil pois a persistência dos dados criava uma dependência. Isso acontece porque os programadores procuram utilizar as extensões específicas (proprietárias) de cada SGBD, que vão além da especificação padrão, pois as mesmas facilitam/agilizam, e muito, o trabalho de desenvolvimento do software. É claro que, se o programador utiliza-se apenas o SQL ANSI, esse problema não aconteceria, ou pelo menos, seria reduzido a, praticamente, alguns pouquíssimos problemas pontuais e de soluções instantâneas. Mas, para muitos, usar apenas o padrão, é ter que reinventar a roda e aumentar os prazos de entrega do produto. Portanto, a API JDBC necessitava de auxílio para permitir de fato, um desacoplamento entre a aplicação e o SGBD.

Sob outra dimensão, a linguagem Java foi construída para oferecer suporte, principalmente, ao paradigma de programação orientada a objeto cujo fundamento se baseia na teoria dos grafos da matemática. Como os SGBDs mais usados no mundo inteiro são relacionais, ou seja, tem como fundamento a teoria dos conjuntos da matemática, criou-se uma dificuldade entre persistir objetos Java em bancos de dados relacionais.

No caso do Java, criou-se uma API denominada de JPA (Java Persistence Application) que especifica e padroniza interfaces para persistir objetos Java e banco de dados relacionais. A partir disso, tem-se diversos frameworks no mercado que implementam a referida API de modo que classes concretas possam realizar o trabalho de fato. Um desses frameworks, muito conhecido pela comunidade Java no mundo todo, é aquele denominado de Hibernate.