The N+1 problem happens when:
Hibernate executes 1 query to fetch parent records
+
N additional queries to fetch child records
This causes:
- too many database calls
- performance degradation
- slow APIs
The Hibernate N+1 problem occurs when Hibernate executes one query
to fetch parent entities and then executes additional queries for
each associated child entity due to lazy loading. This leads to
excessive database round trips and performance degradation. The
most common solution is using JOIN FETCH, EntityGraph, batch
fetching, or DTO projections to load related data efficiently in
fewer queries.
Simple Real-World Example
Suppose: 100 customers each customer has N orders
You want: all customers with their orders
But Hibernate executes:
1 query for customers
100 separate queries for orders
Total: 101 queries
This is: N+1 problem
1. Customer Entity
package com.example.entity;
import jakarta.persistence.*;
import lombok.*;
import java.util.List;
@Entity
@Table(name = "customers")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString(exclude = "orders")
public class Customer {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String name;
@OneToMany(
mappedBy = "customer",
fetch = FetchType.LAZY,
cascade = CascadeType.ALL
)
private List<Order> orders;
}
2. Order Entity
package com.example.entity;
import jakarta.persistence.*;
import lombok.*;
@Entity
@Table(name = "orders")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString(exclude = "customer")
public class Order {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String item;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "customer_id")
private Customer customer;
}
Important Thing FetchType.LAZY
means:
- orders NOT loaded immediately
- loaded only when accessed
The Problematic Code
List<Customer> customers = customerRepository.findAll();
for(Customer c : customers) {
System.out.println(c.getOrders().size());
}
Looks harmless. BUT internally dangerous.
What Happens Internally?
Query 1 : Hibernate fetches customers:
SELECT * FROM customer;
Suppose 100 customers returned.
Then Loop Starts Iteration 1 c.getOrders()
Triggers:
SELECT * FROM orders WHERE customer_id = 1;
Iteration 2
SELECT * FROM orders WHERE customer_id = 2;
Final Total 1 + N queries
If: 100 customers then: 101 queries
Visual Representation
Initial Query
SELECT customers
returns:
C1 C2 C3 C4 C5
Then Lazy Loading
C1 → SELECT orders
C2 → SELECT orders
C3 → SELECT orders
C4 → SELECT orders
C5 → SELECT orders
Many DB round trips. Why Is This Bad?
Database calls are expensive.
Problems:
- network latency
- DB CPU usage
- connection pool pressure
- slow response times
How To Detect N+1 Problem Enable SQL logging.
Spring Boot
spring.jpa.show-sql=true
If you see: repeated similar queries
then likely N+1 issue.
Solution 1. FETCH JOIN
package com.example.repository;
import com.example.entity.Customer;
import org.springframework.data.jpa.repository.*;
import org.springframework.stereotype.Repository;
import java.util.List;
@Repository
public interface CustomerRepository
extends JpaRepository<Customer, Long> {
@Query("""
SELECT DISTINCT c
FROM Customer c
JOIN FETCH c.orders
""")
List<Customer> findAllCustomersWithOrders();
}
What Happens Now? Hibernate executes ONE query:
SELECT c.*, o.*
FROM customer c
JOIN orders o
ON c.id = o.customer_id;
Result Instead of: 101 queries Only: 1 query
Huge improvement.
Visual
Before
1 customer query + 100 order queries
After FETCH JOIN 1 combined query
2. EntityGraph
@EntityGraph(attributePaths = "orders")
List<Customer> findAll();
Tells Hibernate: load orders together
Advantage : Cleaner than custom JPQL sometimes.
3. Batch Fetching - Hibernate optimization.
Example
spring.jpa.properties.hibernate.default_batch_fetch_size=20
What Happens? Instead of: 100 queries Hibernate batches:
SELECT * FROM orders
WHERE customer_id IN (1,2,3...20)
Much fewer queries.
4. DTO Projection - Best for read-heavy APIs.
Example
@Query("""
SELECT new com.dto.CustomerDTO(
c.name,
o.item)
FROM Customer c
JOIN c.orders o
""")
Avoids entity graph entirely. Very efficient.
** Service Class**
package com.example.service;
import com.example.entity.Customer;
import com.example.repository.CustomerRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import java.util.List;
@Service
@RequiredArgsConstructor
public class CustomerService {
private final CustomerRepository customerRepository;
public void printCustomers() {
List<Customer> customers =
customerRepository
.findAllCustomersWithOrders();
for(Customer c : customers) {
System.out.println(c.getName());
System.out.println(c.getOrders().size()
);
}
}
}
Interview Question
Q1. Why Not Use EAGER Fetching?
Many thinks: FetchType.EAGER
solves N+1 but NOT always true.
Why?
EAGER can STILL produce N+1.
And may:
- load unnecessary data
- create huge joins
hurt performance
Example Suppose:Customer
Orders
Payments
Addresses
EAGER loading everything creates:
Cartesian product explosion
massive memory usage
Best Practice Prefer:
LAZY + FETCH JOIN when needed
Q2. Why LAZY Exists If It Causes N+1?
Because:
loading everything always is worse
sometimes child data not needed
LAZY improves:
memory usage
startup cost
flexibility
Problem occurs only when: iterative lazy access happens
Another Dangerous Situation
Nested N+1.
Example
Customer → Orders → Items
Now queries become:
1 + N + N*M
Can explode massively.
Important Hibernate Internals
N+1 happens because:
- Hibernate proxy objects
- lazy initialization
- session-triggered fetch
- Lazy Loading Mechanism
Hibernate initially creates:proxy objects
Actual SQL executed only when accessed.
Example c.getOrders()
This line triggers DB query.
Best Solutions Comparison
Solution Best For
FETCH JOIN Most common
EntityGraph Clean JPA
Batch Fetching Large collections
DTO Projection APIs/reporting
Q3. Does N+1 happen only in OneToMany?
NO. Can happen in:
- ManyToOne
- OneToOne
- nested associations