Hibernate Criteria API vs JPQL vs Native SQL
Fast recall
Quick revision
Core answer
@Query, and integrates with Hibernate's first-level cache and dirty checking. JPA Criteria API (and Spring Data's `Specifications`) is for dynamic queries built programmatically — runtime filters, sorts, joins, type-safe with the JPA metamodel (Order_.status). Native SQL is the escape hatch for database features JPQL cannot express — CTEs, window functions, JSONB operators, LATERAL JOIN, RETURNING, MERGE/UPSERT, full-text search, vendor hints. Native costs: validates only at first execution, loses portability, bypasses L2 cache, skips lifecycle callbacks on bulk operations, leaves L1 stale (requires em.clear() after modifying SQL).Ability to match the query mechanism to the use-case and awareness of trade-offs in testability and portability
Using native SQL for everything because it feels familiar, thereby losing portability and bypassing Hibernate's dirty checking and cache invalidation
Mention the JPA 2.1 Criteria API vs Hibernate's older Criteria API (deprecated), and how Spring Data Specifications build on JPA Criteria
Interview-ready guide
Interview answer
Spring Data JPA and Hibernate give you four ways to query: derived method names, JPQL, Criteria API, and native SQL.
JPQL — the standard choice:
- Object-oriented; references entity class and field names
- Validated at startup with
@Query - Limitation: static string; building dynamic WHERE requires concatenation or Specifications
Criteria API — type-safe dynamic queries:
CriteriaBuilder+CriteriaQuery+Rootbuild the query programmatically- Refactoring-safe: renaming the entity field causes a compile error
- Verbose; use Specifications for cleaner composition
Native SQL — for database-specific features:
- CTEs, window functions, RETURNING, json_agg, LATERAL JOIN — none expressible in JPQL
@Query(value = "...", nativeQuery = true)- Ties you to a specific database; migration becomes harder
Decision: derived methods for simple lookups -> JPQL for readable queries -> Specifications for dynamic multi-filter -> native for database-specific SQL.
Hibernate Criteria API vs JPQL vs Native SQL
Direct Answer
JPQL is the default for ~95% of queries — an object-oriented query language that operates on entity classes and fields, is database-agnostic, validated at startup when declared via @Query, and integrates with Hibernate's first-level cache and dirty checking. JPA Criteria API (and Spring Data's Specifications) is for dynamic queries built programmatically — runtime filters, sorts, joins, type-safe with the JPA metamodel (Order_.status). Native SQL is the escape hatch for database features JPQL cannot express — CTEs, window functions, JSONB operators, LATERAL JOIN, RETURNING, MERGE/UPSERT, full-text search, vendor hints. Native costs: validates only at first execution, loses portability, bypasses L2 cache, skips lifecycle callbacks on bulk operations, leaves L1 stale (requires em.clear() after modifying SQL).
Common Mistakes & Pitfalls
Using native SQL for everything because it feels familiar, thereby losing portability and bypassing Hibernate's dirty checking and cache invalidation
Check your understanding
Answer these without looking back at the article.
- How does Spring Data JPA's `Specification` interface relate to the JPA Criteria API?
- What must you do after running a native bulk UPDATE to keep the Hibernate cache consistent?
- How do you map a native SQL result to a DTO instead of a full entity?
- When would you reach for jOOQ instead of Hibernate?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.