It sounds complicated at first, but the idea is actually pretty simple:

You make one database query to get your parent records, and then Hibernate makes another query for each parent record to load its related data.

The problem usually isn’t visible in your Java code. Everything may look perfectly clean while Hibernate quietly executes dozens or even hundreds of SQL queries behind the scenes.

Let’s understand what actually happens and, more importantly, how to fix it.

First, a Quick Look at ORM

Before ORMs became popular, applications often interacted with databases by writing SQL queries directly.

For example:

SELECT * FROM departments;

Then the application would manually map the result to Java objects.

This works, but as applications grow, managing SQL and object mapping can become tedious.

That’s where Object-Relational Mapping (ORM) comes in.

In the Spring Boot ecosystem, Hibernate is the most commonly used JPA implementation. Instead of writing SQL for every operation, we work with Java entities and relationships, and Hibernate generates the SQL for us.

For example:

@Entity 
public class Department { 

    @Id 
    private Long id; 
    
    private String name; 

    @OneToMany(mappedBy = "department") 
    private List<Employee> employees; 
}

This is convenient because we can work with:

department.getEmployees();

instead of manually writing another SQL query.

But that convenience can sometimes hide what’s happening at the database level.

And that’s where N+1 comes in.

What Exactly Is the N+1 Query Problem?

Let’s say our application has two tables:

Department

Employee

And our entities have a relationship like this:

@Entity public class Department { 

    @Id 
    private Long id; 
    
    private String name; 
    
    @OneToMany(mappedBy = "department") 
    private List employees; 
}

Now imagine we write:

List departments = departmentRepository.findAll();

Hibernate initially executes something similar to:

SELECT * FROM department;

So far, so good.

But then suppose we do this:

for (Department department : departments) { 
    System.out.println(department.getEmployees()); 
}

Because employees is lazy-loaded, Hibernate may now execute another query for every department:

SELECT * FROM employee WHERE department_id = 1; 
SELECT * FROM employee WHERE department_id = 2; 
SELECT * FROM employee WHERE department_id = 3;

So if we had 50 departments, we could end up with:

1 query → fetch 50 departments 50 queries → fetch employees for each department Total = 51 queries

That’s the N+1 problem.

The 1 represents the initial query, while N represents the additional queries generated for the N parent records.

Why Is This a Problem?

One query doesn’t sound scary.

Even ten queries might not immediately cause a problem.

But imagine an API endpoint that returns 500 departments.

Instead of:

1 database query

you could end up with:

1 + 500 = 501 queries

And this is happening during a single API request.

Now imagine multiple users hitting the endpoint simultaneously.

The application starts putting unnecessary pressure on the database:

API Request 
    | 
    v 
Spring Boot 
    | 
    v 
Hibernate 
    | 
    +---- Query 1 
    | 
    +---- Query 2 
    | 
    +---- Query 3 
    | 
    +---- Query 4 
    | 
    ... 
    | 
    +---- Query N 
    | 
    v 
Database

The result can be:

• Increased database load

• Higher API response times

• More network round trips

• Poor scalability

• Connection pool pressure

• Performance degradation under load

The frustrating part is that the Java code itself may look completely reasonable.

How Does Lazy Loading Contribute to N+1?

This is where things get interesting.

For collections such as @OneToMany, Hibernate generally uses lazy loading by default.

That means Hibernate doesn’t immediately load all employees when it loads a department.

Instead, it waits until you actually access:

department.getEmployees();

This is usually a good thing.

You don’t want Hibernate loading every related object when you don’t need it.

The problem occurs when you load many parent entities and then access the lazy relationship for each one.

For example:

List departments = departmentRepository.findAll(); 

for (Department department : departments) {                           department.getEmployees().size(); 
}

This can trigger the classic:

1 + N

query pattern.

So lazy loading itself isn’t bad.

The problem is how the relationship is accessed.

How Can We Fix the N+1 Problem?

There isn’t one universal solution.

The right approach depends on what data your API actually needs.

Here are some of the most useful approaches.

1. Use DTOs for API Responses

For REST APIs, DTOs are often one of the cleanest approaches.

Instead of returning your entire entity graph, define exactly what the API needs.

For example:

public record DepartmentDTO( Long id, String name ) {}

Then query only the required fields.

For example:

@Query(""" 
    SELECT new com.example.dto.DepartmentDTO(d.id, d.name) 
    FROM Department d 
""") 
List findDepartmentDTOs();

This prevents Hibernate from loading relationships that your API doesn’t actually need.

Why I like this approach

DTOs make the API contract explicit.

You’re essentially saying:

“I need these three fields.”

instead of:

“Give me the entire Department entity and whatever relationships happen to be attached to it.”

For real-world REST APIs, this can also help prevent:

• Accidental lazy-loading queries

• Large response payloads

• Circular entity serialization

• Exposing internal entity structure

2. Use JOIN FETCH

If you actually need the related entities, JOIN FETCH is another common solution.

For example:

@Query(""" 
    SELECT DISTINCT d FROM Department d JOIN FETCH d.employees """) 
List findAllDepartmentsWithEmployees();

Hibernate can generate a SQL join instead of separately querying employees for every department.

Conceptually, we’re moving from:

Department query 
      + 
N employee queries

to something closer to:

One joined query

For example:

SELECT d.*, e.* 
FROM department d 
JOIN employee e 
    ON e.department_id = d.id;

Why DISTINCT?

A SQL join can produce multiple rows for the same department if that department has multiple employees.

For example:

Department 1 → Employee A 
Department 1 → Employee B 
Department 1 → Employee C

Hibernate therefore needs to make sure we don’t end up with duplicate Department objects in the result.

That’s why you’ll often see:

SELECT DISTINCT d

with collection fetch joins.

3. Use @EntityGraph

If you don’t want to write custom JPQL, @EntityGraph provides a declarative way of specifying which relationships should be fetched.

For example:

@EntityGraph(attributePaths = {"employees"}) 
List findAll();

Now you’re telling Hibernate:

“When executing this query, fetch the employees along with the departments.”

This can make repository code easier to read, especially when the query itself doesn’t need complicated filtering or joins.

I particularly like @EntityGraph when the repository query is otherwise simple.

4. Use Batch Fetching

Sometimes fetching everything in one giant join isn’t the best option.

Hibernate also supports batch fetching.

For example:

@BatchSize(size = 20) 
@OneToMany(mappedBy = "department") 
private List employees;

Instead of doing:

SELECT * FROM employee WHERE department_id = 1; 
SELECT * FROM employee WHERE department_id = 2; 
SELECT * FROM employee WHERE department_id = 3;

Hibernate can group IDs together and execute queries more like:

SELECT * 
FROM employee 
WHERE department_id IN (1, 2, 3, ..., 20);

So instead of N individual queries, Hibernate can reduce the number of database round trips significantly.

You can also configure a default batch size globally using:

spring.jpa.properties.hibernate.default_batch_fetch_size=20

This doesn’t necessarily turn N+1 into exactly one query, but it can dramatically reduce the number of queries.

5. What About FetchType.EAGER?

This is one of the first solutions people usually think of:

@OneToMany( 
    mappedBy = "department", 
    fetch = FetchType.EAGER 
) 
private List employees;

It sounds reasonable:

“If lazy loading causes N+1, let’s just make it eager.”

But this is generally not a good global solution.

The problem is that eager loading means the relationship is expected to be available whenever the entity is loaded.

That can lead to:

• Unnecessary data being loaded

• Larger SQL queries

• More memory consumption

• Unexpected performance problems

• Difficult-to-control entity graphs

And importantly, changing a relationship to EAGER does not guarantee that every query will magically become a single efficient SQL query.

The better approach is usually to decide per use case what data should be fetched.

A Practical Way to Think About It

When working with JPA/Hibernate, I find this mental model useful:

Don’t ask:

“Should this relationship be LAZY or EAGER?”

Instead, ask:

“What data does this particular use case need?”

For example:

Use case 1 — Department list

The UI only needs:

Department ID Department Name

Use a DTO projection.

Use case 2 — Department details

The UI needs:

Department 
+ 
Employees

A fetch join or entity graph may make sense.

Use case 3 — Large number of departments

Fetching everything through one massive join may not be ideal.

Batch fetching might be more appropriate.

The solution should depend on the query and the amount of data involved.

How Do You Actually Detect N+1?

One of the easiest ways is simply to look at the SQL Hibernate is generating.

For example, if your logs contain something like:

select ... from department 
select ... from employee where department_id=? 
select ... from employee where department_id=? 
select ... from employee where department_id=? 
select ... from employee where department_id=?

and that second query keeps repeating, that’s a strong indication that you may have an N+1 problem.

In a real application, database monitoring and SQL logging can help identify these patterns before they become serious production issues.

Final Thoughts

The N+1 query problem is one of those issues that makes you appreciate both the power and the trade-offs of ORM frameworks.

Hibernate saves us from writing a huge amount of boilerplate database code, but that abstraction doesn’t mean we can completely ignore what is happening at the SQL level.

The key lesson for me is:

If you’re using an ORM, you should still understand the SQL it generates.

When you notice an N+1 problem, don’t immediately switch everything to EAGER.

Instead, look at what the API actually needs and choose the appropriate strategy:

• DTO projections → when you only need specific fields

• JOIN FETCH → when you need related entities in the same query

• @EntityGraph → when you want declarative fetch planning

• Batch fetching → when loading relationships in groups makes sense

• EAGER → use cautiously rather than as a blanket fix

Once you start thinking about the database queries behind your JPA code, Hibernate becomes much less of a “black box” and much easier to optimize.