Fetch Types & the N+1 Problem

In JPA and Hibernate, fetch types determine when related entities are loaded from the database. Choosing the wrong fetch strategy is one of the most common causes of performance issues in Spring Boot applications—most notably the N+1 query problem.

Understanding fetch types and knowing how to solve the N+1 problem is critical for building scalable, high-performance Spring Data JPA applications, especially in real-world enterprise systems.

What is a Fetch Type?

A fetch type defines when associated entities are retrieved from the database relative to the parent entity.

JPA provides two fetch strategies:

FetchType.EAGER
FetchType.LAZY

FetchType.EAGER

With FetchType.EAGER, related entities are loaded immediately along with the parent entity, regardless of whether they are actually used.

@OneToOne(fetch = FetchType.EAGER)
private Profile profile;

Behavior

Data is loaded at query execution time
Hibernate may use:
- SQL JOINs
- OR additional SELECT queries
Fetching happens even if the relationship is never used

Default For

@OneToOne
@ManyToOne

Advantages

Simple and easy to understand
No risk of LazyInitializationException
Suitable for small datasets or always-required relationships

Disadvantages

Loads unnecessary data
Higher memory consumption
Limited control over generated SQL
Frequently causes the N+1 query problem
Poor scalability in large or complex applications

FetchType.LAZY

With FetchType.LAZY, related entities are loaded only when they are accessed in the code.

@OneToMany(fetch = FetchType.LAZY)
private List<Order> orders;

Behavior

Uses proxy objects instead of real data initially
SQL query is executed on first access
Data is fetched only when actually needed

Default For

@OneToMany
@ManyToMany

Advantages

Better overall performance
Lower memory usage
Fine-grained control over database queries
Ideal for large datasets
Recommended default for most relationships

Disadvantages

Can cause LazyInitializationException when:

Accessed outside a transaction
Accessed after the Hibernate session is closed

Default Fetch Types

In JPA, each relationship type has a default fetch strategy that determines when related data is loaded from the database.

@OneToOne → EAGER

The related entity is loaded immediately with the parent entity.
@ManyToOne → EAGER

The parent reference is fetched instantly, as it is usually required.
@OneToMany → LAZY

Child collections are loaded only when explicitly accessed, improving performance.
@ManyToMany → LAZY

Associated collections are fetched on demand to avoid heavy joins and large result sets.

Difference between `FetchType.EAGER` and `FetchType.LAZY` in JPA:

Feature	FetchType.EAGER	FetchType.LAZY
When data is loaded	Immediately along with the parent entity	Only when accessed in code (on-demand)
Default for	`@OneToOne`, `@ManyToOne`	`@OneToMany`, `@ManyToMany`
SQL behavior	May use JOIN or additional SELECT; loads all related entities upfront	Uses proxy objects; queries executed only when accessed
Memory usage	Higher, loads unnecessary data	Lower, loads only what’s needed
Performance	Can cause N+1 query problem and slower performance with large datasets	More efficient for large datasets; reduces unnecessary DB access
Risk of LazyInitializationException	No	Yes, if accessed outside transaction/session
Use case	Small datasets or always-required relationships	Large datasets or optional relationships
Control over queries	Limited	Full control

What is the N+1 Query Problem?

The N+1 query problem is a common performance issue in JPA and Hibernate that occurs when related entities are fetched inefficiently.

How It Happens

Hibernate executes:

1 query to fetch the parent entities
N additional queries to fetch related child entities (one per parent)

Example Scenario

List<User> users = userRepository.findAll();

for (User user : users) {
    System.out.println(user.getOrders().size());
}

If the orders relationship is LAZY-loaded, Hibernate triggers a separate query for each user when getOrders() is accessed.

SQL Executed

SELECT*FROM users;-- 1 query
SELECT*FROM ordersWHERE user_id=1;
SELECT*FROM ordersWHERE user_id=2;
SELECT*FROM ordersWHERE user_id=3;
...

Result:

If 1,000 users are loaded → 1,001 SQL queries are executed.

Why This Is a Problem

The N+1 issue causes:

Slow response times
Excessive database round trips
High database load
Poor application scalability
Performance degradation under heavy traffic

Why the N+1 Problem Happens

Common causes include:

Default LAZY loading
Accessing relationships inside loops
Missing fetch joins or entity graphs
Poor repository query design
Returning entities directly from REST APIs
Overusing bidirectional relationships

—> The N+1 problem is not a Hibernate bug—it’s a design issue.

How to Detect the N+1 Problem

Enable SQL Logging

spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

Warning Signs

Repeated similar SELECT statements
Queries executed inside loops
Unexpected database spikes
Slow API responses with small data

? Tools like Hibernate Statistics, Datasource Proxy, or APM tools can help detect it early.

Solutions to the N+1 Problem

Solution 1: Fetch Join (Best Performance)

@Query("SELECT u FROM User u JOIN FETCH u.orders")
List<User>findAllWithOrders();

Loads parent and child entities in one SQL query
Most efficient and widely used solution
Ideal for service-layer queries

Solution 2: EntityGraph (Clean & Flexible)

@EntityGraph(attributePaths = "orders")
List<User>findAll();

No JPQL modification
Declarative and reusable
Excellent for complex domain models
Cleaner than fetch joins

Solution 3: Batch Fetching

spring.jpa.properties.hibernate.default_batch_fetch_size=10

Fetches related entities in batches
Reduces total query count
Easy configuration-based optimization
Useful when fetch joins are not possible

Solution 4: DTO Projection (Best for APIs)

@Query("SELECT new com.example.dto.UserDTO(u.id, u.name) FROM User u")
List<UserDTO>fetchUsers();

No entity loading
Fast and lightweight
Best for REST APIs and reporting
Avoids Lazy & N+1 issues completely

Solution to Avoid: Global EAGER Fetching

@OneToMany(fetch = FetchType.EAGER)

Why Avoid?

Loads excessive data
Memory overhead
Unpredictable SQL
Poor performance under load
Hard to optimize later

—> Never use EAGER blindly on collections

Best Practices (Production-Ready)

Default to LAZY fetching
Fetch only what you need, when you need it
Use Fetch Join or EntityGraph intentionally
Prefer DTOs for API responses
Avoid exposing entities directly in controllers
Monitor SQL logs regularly
Optimize queries, not entities

Conclusion

Fetch strategies in JPA and Hibernate play a crucial role in determining application performance, scalability, and database efficiency. Properly choosing between LAZY and EAGER loading, and addressing the N+1 problem using techniques like fetch joins, EntityGraphs, batch fetching, and DTO projections, ensures your Spring Data JPA applications remain fast, efficient, and production-ready.