What is JPA vs Hibernate?

Detailed explanation

JPA, originally Java Persistence API and now Jakarta Persistence, is a specification for object-relational mapping and persistence in Java. It defines standard annotations such as @Entity and @Id, APIs such as EntityManager, and rules for entity lifecycle, relationships, queries, and transactions. Hibernate ORM is a widely used implementation, or persistence provider, of that specification. The key distinction is contract versus implementation: JPA defines the expected behaviour, while Hibernate supplies the runtime code that performs the persistence work.

For example, an entity declared as @Entity class User { @Id @GeneratedValue Long id; String name; } uses standard persistence annotations. In modern applications, these usually come from jakarta.persistence; older applications use javax.persistence. When Hibernate is configured as the provider, it reads the mapping metadata and maps the entity to database tables and columns. Calling EntityManager.persist(user) makes a new instance managed and schedules its insertion. SQL execution depends on flushing and identifier-generation requirements, so persist does not always issue an INSERT immediately. Hibernate ultimately accesses a relational database through JDBC.

Both JPA and Hibernate support concepts such as a persistence context, managed entities, relationship loading, and dirty checking. JPA specifies their observable behaviour; Hibernate implements the mechanisms. Hibernate also exposes its native Session API, HQL, and provider-specific mapping and tuning options. JPQL is the standard query language, while HQL supports additional Hibernate capabilities. Caching needs a careful distinction: persistence-context identity and an optional shared-cache contract are part of JPA, while Hibernate offers concrete second-level-cache integration and a provider-specific query cache. Therefore, saying that caching exists only in Hibernate is inaccurate.

Using JPA APIs reduces coupling to one provider and makes migration to alternatives such as EclipseLink easier. However, portability is not automatic: native SQL, database-specific features, provider extensions, and performance characteristics can still require changes. Interviewers usually expect you to explain this trade-off rather than merely expand the acronyms. Prefer standard JPA features for ordinary persistence, and adopt Hibernate-specific capabilities deliberately when their benefits justify the dependency.

Key points to remember

• JPA is a persistence specification; Hibernate ORM is a provider that implements it.
• EntityManager and JPQL are standard JPA APIs; Session and extended HQL are Hibernate APIs.
• Hibernate interprets entity mappings, tracks managed state, and executes database operations through JDBC.
• Standard JPA usage improves provider portability but does not eliminate database or performance differences.
• JPA defines some caching contracts; Hibernate adds concrete cache integrations and provider-specific capabilities.

Common mistakes candidates make

• Describing JPA and Hibernate as two competing ORM implementations.
• Claiming that JPA has no caching support or that every persist call immediately executes an INSERT.
• Assuming JPA annotations alone guarantee portability despite native SQL and Hibernate-specific extensions.

Likely follow-up questions