---

Introduction

One of the biggest performance problems in Hibernate and Spring Data JPA is the N+1 Query Problem.

Imagine retrieving 100 customers and then loading each customer's accounts individually.

Instead of executing 1 SQL query, Hibernate executes:

• 1 query for customers
• 100 queries for accounts

Total:

101 SQL Queries

This significantly increases:

• Database load
• Network latency
• Response time

Spring Data JPA provides EntityGraph to efficiently fetch related entities using optimized SQL.

---

EntityGraph Architecture

flowchart LR

Repository --> EntityGraph

EntityGraph --> Hibernate

Hibernate --> SingleSQL

SingleSQL --> Database

---

Q1. What is EntityGraph?

Answer

EntityGraph is a JPA feature that specifies which related entities should be fetched together in a single query.

Instead of relying only on

• Lazy Loading
• Eager Loading

EntityGraph allows developers to control fetching per query.

Benefits

• Solves N+1 problem
• Improves performance
• Reduces SQL queries
• Flexible fetch strategy

---

Q2. What is the N+1 Query Problem?

Example

Retrieve

100 Customers

Each customer has Accounts.

Without EntityGraph

1 Query → Customers

100 Queries → Accounts

Total = 101 Queries

N+1 Problem

flowchart TD

CustomerQuery --> Customer1

CustomerQuery --> Customer2

CustomerQuery --> Customer3

Customer1 --> AccountQuery1

Customer2 --> AccountQuery2

Customer3 --> AccountQuery3

This results in excessive database round trips.

---

Q3. How does EntityGraph solve the N+1 problem?

Example

@EntityGraph(
attributePaths = {

"accounts"

})

List<Customer>

findAll();

Generated SQL

SELECT

*

FROM CUSTOMER

LEFT JOIN ACCOUNT

Optimized Fetch

flowchart LR

SingleQuery --> Customer

SingleQuery --> Account

Customer --> Application

Only one optimized query is executed.

---

Q4. What is @EntityGraph?

@EntityGraph tells Spring Data JPA which associations should be eagerly fetched for a specific repository method.

Example

@EntityGraph(

attributePaths={

"department"

})

List<Employee>

findAll();

Only the specified relationship is eagerly loaded.

---

Q5. What is NamedEntityGraph?

Named graphs are reusable entity graphs.

Example

@NamedEntityGraph(

name="customer.accounts",

attributeNodes={

@NamedAttributeNode(

"accounts")

})

Repository

@EntityGraph(

value="customer.accounts")

Named Graph

flowchart LR

NamedGraph --> Repository

Repository --> Hibernate

Hibernate --> Database

Useful when multiple repository methods use the same fetch plan.

---

Q6. What is FetchGraph vs LoadGraph?

JPA defines two graph types.

FetchGraph	LoadGraph
Fetch only specified attributes	Fetch specified + default eager attributes
Better performance	More flexible

Choose FetchGraph when precise control is required.

---

Q7. EntityGraph vs FetchType.EAGER

FetchType.EAGER

• Permanent
• Applied everywhere
• Can over-fetch data

EntityGraph

• Query specific
• Flexible
• Better performance

Example

@EntityGraph(

attributePaths={

"orders"

})

EntityGraph is generally preferred over EAGER fetching.

---

Q8. EntityGraph vs JOIN FETCH

JPQL supports

SELECT c

FROM Customer c

JOIN FETCH

c.orders

Comparison

JOIN FETCH	EntityGraph
Query-based	Annotation-based
Less reusable	Highly reusable
JPQL specific	Repository friendly

Both generate optimized SQL.

---

Q9. When should EntityGraph be used?

Ideal scenarios

• Parent-child relationships
• Dashboard APIs
• REST endpoints
• Reporting
• Customer order history
• Banking account summaries

Avoid using EntityGraph when related data is unnecessary.

---

Q10. EntityGraph Best Practices

Default to LAZY

Keep entity mappings lazy.

---

Use EntityGraph

For query-specific eager loading.

---

Avoid Global EAGER

It often loads unnecessary data.

---

Reuse NamedEntityGraphs

Avoid duplicate fetch definitions.

---

Monitor SQL

Verify generated queries using Hibernate SQL logs.

---

Banking Example

flowchart TD

CustomerRepository --> EntityGraph

EntityGraph --> Customer

Customer --> Accounts

Customer --> Loans

Customer --> Cards

Hibernate --> PostgreSQL

Customer summary is loaded with all required relationships in a single query.

---

Common Interview Questions

• What is EntityGraph?
• What is the N+1 problem?
• How does EntityGraph solve it?
• What is @EntityGraph?
• What is NamedEntityGraph?
• FetchGraph vs LoadGraph?
• EntityGraph vs EAGER?
• EntityGraph vs JOIN FETCH?
• When should EntityGraph be used?
• EntityGraph best practices?

---

Quick Revision

Topic	Summary
EntityGraph	Optimized fetching strategy
@EntityGraph	Repository-level fetch plan
NamedEntityGraph	Reusable fetch graph
N+1 Problem	Excessive SQL queries
Lazy Loading	Load on demand
Eager Loading	Immediate loading
FetchGraph	Fetch specified attributes only
LoadGraph	Fetch specified + eager attributes
JOIN FETCH	JPQL fetch optimization
EntityGraph	Query-specific optimization

---

EntityGraph Execution Flow

sequenceDiagram
Application->>Repository: findCustomer()
Repository->>@EntityGraph: Apply Fetch Plan
@EntityGraph->>Hibernate: Generate JOIN
Hibernate->>Database: Single SQL Query
Database-->>Hibernate: Customer + Accounts
Hibernate-->>Repository: Entity Graph
Repository-->>Application: Complete Object

---

Production Example – Banking Customer Dashboard

A banking application displays a customer dashboard.

Requirements

• Customer profile
• Savings accounts
• Credit cards
• Active loans
• Investment accounts

Without EntityGraph

1 Query → Customer

1 Query → Accounts

1 Query → Cards

1 Query → Loans

1 Query → Investments

Total = 5 Queries

For 500 customers, this quickly becomes thousands of SQL queries.

Solution

@EntityGraph(attributePaths = {
    "accounts",
    "cards",
    "loans",
    "investments"
})
Optional<Customer> findByCustomerId(Long id);

Generated SQL

SELECT c.*, a.*, cd.*, l.*, i.*
FROM CUSTOMER c
LEFT JOIN ACCOUNT a ON ...
LEFT JOIN CARD cd ON ...
LEFT JOIN LOAN l ON ...
LEFT JOIN INVESTMENT i ON ...

flowchart LR

CustomerService --> CustomerRepository

CustomerRepository --> EntityGraph

EntityGraph --> Hibernate

Hibernate --> PostgreSQL

PostgreSQL --> CustomerWithRelations

The dashboard loads all required information using a single optimized query, dramatically reducing database round trips and improving response time.

---

Key Takeaways

• EntityGraph is a JPA feature that optimizes fetching of related entities on a per-query basis.
• It is one of the best solutions for eliminating the N+1 Query Problem in Spring Data JPA.
• @EntityGraph allows repository methods to define exactly which associations should be fetched eagerly.
• NamedEntityGraph enables reusable fetch plans shared across multiple repository methods.
• Prefer FetchGraph when you need precise control over fetched associations.
• Keep entity relationships LAZY by default and use EntityGraph selectively instead of global FetchType.EAGER.
• EntityGraph is cleaner and more reusable than embedding JOIN FETCH clauses in every JPQL query.
• Monitoring generated SQL is essential to verify that EntityGraph is reducing query count and improving application performance in production.