DEV Community

Tapas Pal
Tapas Pal

Posted on

What Is the N+1 Problem in Hibernate/JPA? How to resolve it? Interview Q&A

The N+1 problem happens when:

Hibernate executes 1 query to fetch parent records
+
N additional queries to fetch child records
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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;
}
Enter fullscreen mode Exit fullscreen mode

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());
}
Enter fullscreen mode Exit fullscreen mode

Looks harmless. BUT internally dangerous.
What Happens Internally?
Query 1 : Hibernate fetches customers:

SELECT * FROM customer;
Enter fullscreen mode Exit fullscreen mode

Suppose 100 customers returned.

Then Loop Starts Iteration 1 c.getOrders()
Triggers:

SELECT * FROM orders WHERE customer_id = 1;
Enter fullscreen mode Exit fullscreen mode

Iteration 2

SELECT * FROM orders WHERE customer_id = 2;
Enter fullscreen mode Exit fullscreen mode

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();
}
Enter fullscreen mode Exit fullscreen mode

What Happens Now? Hibernate executes ONE query:

SELECT c.*, o.*
FROM customer c
JOIN orders o
ON c.id = o.customer_id;
Enter fullscreen mode Exit fullscreen mode

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();
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
       """)
Enter fullscreen mode Exit fullscreen mode

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()
            );
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)