Cloud Parts

Hibernate ORM

The standard object-relational mapper for Java: it maps annotated classes to tables, tracks changes to loaded objects in a session and writes them back as SQL, and implements Jakarta Persistence (JPA).

What it is
Object-relational mapping (full orms)
Type
Open source
Made by
Hibernate project (Commonhaus Foundation)
License
Apache 2.0 since 7.0 (LGPL 2.1 before)
Facts checked
8 October 2026
Website Source code

What it is

You annotate plain Java classes with @Entity, @Id and association mappings such as @ManyToOne, and Hibernate generates the SQL to load and save them. Work happens in a session (Session, or JPA’s EntityManager). A stateful session has a persistence context, which Hibernate also calls the first-level cache: every entity loaded in it is tracked, the same row always gives the same object, and changes are found by automatic dirty checking and written when the session flushes, with no explicit update call. Before running a query, Hibernate flushes pending changes that could affect its result. A StatelessSession skips all of that: every fetch and every update is an explicit operation.

Queries are written in HQL, an object-oriented superset of JPA’s query language, or built with the criteria API; since Hibernate 6 every HQL query is compiled to a criteria query before it becomes SQL. Native SQL queries are there when HQL can’t express something. Associations should be lazy by default, and the guide is blunt that lazy fetching is the usual source of N+1 selects: fetch what a transaction needs up front with join fetch or an entity graph. Hibernate can export a schema inferred from the mappings, keeps an optional second-level cache shared across sessions, and talks to PostgreSQL, CockroachDB, MySQL, MariaDB, Oracle, SQL Server, DB2, H2 and others through their JDBC drivers. It inspired JPA, implements the latest version of it, and is governed as a Commonhaus Foundation project; version 7.4 is the latest stable series, with 8.0 (Jakarta Persistence 4.0) in development.

Why teams pick it

  • The most widely used JPA implementation, with mapping for inheritance, embeddables, composite keys, versioning and natural ids
  • Change tracking and a unit of work per session: modify loaded objects and the right UPDATEs run at flush
  • Fine control over fetching (join, batch and subselect fetching, entity graphs, fetch profiles) plus a second-level cache
  • Runs on many databases through JDBC dialects, and drops to native SQL when needed

Watch out for

  • Lazy associations make N+1 selects easy to write; avoiding them means planning fetches per use case
  • The persistence context is “magical”: automatic flushes, detached entities and proxies surprise developers who don’t know the rules
  • A large API and configuration surface (HQL, criteria, caches, fetch strategies) with a steep learning curve
  • Schema export suits tests and prototypes; versioned production migrations need a separate tool

Alternatives

What all full orms have in common →
Active Record (Ruby on Rails)Open sourceThe model layer of Ruby on Rails and the best-known implementation of Fowler’s Active Record pattern: each Ruby class wraps a table, each object a row, and objects load, validate and save themselves.Entity Framework CoreOpen sourceMicrosoft’s object-relational mapper for .NET: you query C# classes with LINQ, a `DbContext` tracks the entities it loads, and `SaveChanges` writes every change back as SQL through a pluggable database provider.Prisma ORMOpen sourceA TypeScript ORM driven by a schema file: you declare models once, Prisma generates a fully typed client and SQL migrations from them, and queries return plain JavaScript objects.SQLAlchemyOpen sourceA Python database toolkit in two layers: a SQL expression layer (Core) that builds and runs SQL, and an ORM on top of it that maps classes to tables with an identity map and a unit of work.Tortoise ORMOpen sourceAn async-native Python ORM with a Django-style API: models as classes, `await Model.filter(...)` queries, and built-in migrations since 1.0.

How it fits with other technologies

The N+1 select the Hibernate guide warns about, and the join fetch that fixes it · java

@Entity
class Book {
    @Id String isbn;
    String title;
    @ManyToMany List<Author> authors;   // lazy by default
}

// one select for the books, then one more per book when its authors are touched
List<Book> books = session.createSelectionQuery("from Book order by isbn", Book.class)
        .getResultList();
books.forEach(book -> book.authors.forEach(a -> System.out.println(book.title + " by " + a.name)));

// one select with a left join: authors arrive with their books
List<Book> fetched = session.createSelectionQuery(
        "from Book b left join fetch b.authors order by b.isbn", Book.class)
        .getResultList();

See it in a real stack

No architecture uses Hibernate ORM yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2001–2025

In 2001 Java’s official answer to persistence was the entity bean of Enterprise JavaBeans 2: heavyweight components managed by an application server. Gavin King, working with colleagues at Cirrus Technologies, started Hibernate that year out of frustration with entity beans. It mapped plain Java objects to tables instead, quickly overtook its open-source and commercial rivals, and the book Hibernate in Action, which King wrote with Christian Bauer, spread the approach.

In 2004 King and Bauer joined JBoss, later part of Red Hat, and other early contributors followed. King joined the EJB 3 expert group and persuaded it to deprecate entity beans in favour of a new persistence API modelled on Hibernate. Members of the TopLink team joined in, and the Java Persistence API 1.0 was finalised in May 2006. Hibernate became an implementation of that standard while keeping its own richer API.

Hibernate 6.0 in 2022 was a major redesign touching the APIs, mapping annotations and query language. Hibernate 7.0 in May 2025 moved from the LGPL to the Apache License and to Jakarta Persistence 3.2. The project is now governed under the Commonhaus Foundation, and its own guide admits the team’s biggest regret: not giving the explicit, persistence-context-free StatelessSession more attention twenty years ago.

Why it’s built this way

Plain Java objects instead of container-managed beans
EJB 2 entity beans tied persistence to the application server and its component model. Mapping ordinary classes made persistence testable and usable anywhere, which was the frustration that started the project.
Transparent persistence through a session
Tracking every loaded object and flushing changes automatically meant application code could just modify objects. The cost, the team later wrote, was a loss of direct control and traps for inexperienced users.
Don’t pretend the database isn’t relational
The guide says acceptable performance is impossible without acknowledging the underlying relational model, so Hibernate keeps SQL concepts such as joins, fetch plans and native queries in view.
Standardise the approach as JPA
Joining the EJB 3 expert group turned Hibernate’s design into a vendor-neutral Java standard, so code written against JPA could run on Hibernate, TopLink or others.

Timeline

  1. 2001

    Gavin King starts Hibernate as an alternative to EJB 2 entity beans

  2. 2004

    King and Christian Bauer join JBoss

  3. 2005

    Hibernate 3.0 adds JDK 5 annotations

  4. 2006

    JPA 1.0, modelled on Hibernate, is finalised in May

  5. 2022

    Hibernate 6.0, a redesign of the APIs and query language

  6. 2025

    Hibernate 7.0 moves to the Apache License and Jakarta Persistence 3.2

Sources5 · facts checked 8 October 2026

Improve this page on GitHub