Data Access — JPA vs JDBC vs MyBatis vs jOOQ
Fast recall
Quick revision
Core answer
Breadth of data access options; honest trade-offs; when each tool earns its place; ability to blend tools intelligently
'JPA everywhere' blindly; fighting JPA for complex analytics queries instead of reaching for jOOQ or JDBC
Discuss blending JPA with jOOQ/JDBC, N+1 pitfalls, Hibernate 6 improvements, Spring Data JDBC, and the 'wrong queries vs wrong tool' framing
Interview-ready guide
Interview answer
Java has four dominant SQL data access styles, each at a different abstraction level.
JDBC via `JdbcClient`:
- Raw SQL with
RowMapper - Spring 6.1 fluent API; cleaner than old
JdbcTemplate - Maximum control, zero ORM overhead, verbose for CRUD
JPA / Hibernate via Spring Data JPA:
- Heavyweight ORM with entity annotations
- JPQL, Criteria, derived methods, native queries
- Productivity for CRUD and rich object graphs
- Risks — N+1,
LazyInitializationException, dirty-check surprises
MyBatis:
- SQL-first; you own SQL in XML or annotations
- Popular in Asia and for legacy DB integration
- Friendly to stored procs and dynamic SQL
jOOQ:
- Typesafe SQL via code-generated schema
- Compile-time validation, autocomplete on every column
- Excellent for analytics, CTEs, window functions
Decision rule:
- CRUD with relationships -> Spring Data JPA
- Reporting and analytics -> jOOQ
- Legacy schema with stored procs -> MyBatis
- Hot path with hand-tuned SQL -> JdbcClient
- DDD aggregates without ORM complexity -> Spring Data JDBC
Blending tools:
- Real projects often use JPA for 80% CRUD plus jOOQ or JdbcClient for the analytical 20%
- Both share the same
DataSourceand participate in the same transaction - Don't fight the tool — pick the one that matches the workload
The honest framing:
- 90% of performance problems are wrong queries, not wrong tool
- Hibernate 6 improves JPQL, streaming, and Criteria
- For new services in 2026, default to Spring Data JPA and add jOOQ or JdbcClient for the queries JPA makes awkward
Data Access — JPA vs JDBC vs MyBatis vs jOOQ
Direct Answer
JDBC (JdbcTemplate/JdbcClient) is the raw-SQL layer — maximum control, zero ORM overhead, verbose for CRUD. JPA/Hibernate (Spring Data JPA) is the heavyweight ORM — productivity for CRUD and rich object graphs, but N+1, lazy-loading and dirty-checking pitfalls. MyBatis is SQL-first mapping — you own the SQL, MyBatis maps to objects; common in legacy DB integration. jOOQ is typesafe SQL via code-generated schema — compile-time validation, excellent for analytics and CTEs. Decision rule: CRUD with relationships -> JPA; reporting/complex SQL -> jOOQ; legacy schema and stored procs -> MyBatis; hot path with custom SQL -> JdbcClient. Real projects blend — JPA for 80% CRUD, jOOQ or JDBC for the awkward 20%.
Common Mistakes & Pitfalls
'JPA everywhere' blindly; fighting JPA for complex analytics queries instead of reaching for jOOQ or JDBC
Check your understanding
Answer these without looking back at the article.
- How do you avoid the N+1 problem in Spring Data JPA?
- When would you mix JPA and jOOQ in the same service?
- What is Spring Data JDBC and how is it different from JPA?
- What changed in Hibernate 6 that is worth knowing in production?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.