Hibernate N+1 Problem: How 101 SQL Queries Made a Page Load in 12 Seconds

You've been there. You deploy a seemingly innocent Spring Boot REST endpoint that fetches a list of invoices. In dev, with 10 rows, it's snappy. In staging with 500 rows, it's sluggish. In production with 10,000 invoices, your page takes 12 seconds to load and your DBA is calling you at 2 AM. Welcome to the Hibernate N+1 query problem.

I've debugged this exact scenario in a SaaS billing system handling 2 million invoices. The root cause was always the same: lazy-loading entity associations without proper fetch planning. Hibernate, by default, defers loading of child collections until they are accessed. When you iterate over a parent list and access each child collection, Hibernate fires one SQL query per parent. That's 1 (parent fetch) + N (child fetches) queries. For a list of 100 invoices each with 3 line items, that's 301 queries. Now scale that to thousands.

In this article, I'll show you how to spot the N+1 problem using Hibernate query statistics, how to fix it with JOIN FETCH and @EntityGraph, and how to avoid it in the first place. We'll use a realistic e-commerce order management domain. By the end, you'll know how to cut your query count from hundreds to single digits.

Understanding the N+1 Query Pattern

The N+1 problem is deceptively simple. You have an entity like Order with a @OneToMany to OrderItem. You write a repository method findAll() and then in your service you loop over orders to calculate total items. Hibernate, being lazy by default, fires 1 query for orders and then for each order, when you access order.getItems(), it fires another query. That's 1 + N.

Let me show you with code. Consider these entities:

@Entity
@Table(name = "orders")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String customerName;

    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    private List<OrderItem> items = new ArrayList<>();

    // getters, setters
}

@Entity
@Table(name = "order_items")
public class OrderItem {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String productName;
    private BigDecimal price;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")
    private Order order;

    // getters, setters
}

What the Official Docs Won't Tell You

The official Hibernate documentation explains JOIN FETCH and @EntityGraph, but it doesn't tell you the gritty truth: these annotations are easy to misuse, and they can actually make performance worse if you're not careful. For instance, JOIN FETCH on multiple collections creates a Cartesian product. If you join fetch both items and payments on an order, you'll get (number of items * number of payments) rows per order. That's a data explosion.

Another thing the docs gloss over: @EntityGraph works beautifully with Spring Data JPA's derived query methods, but it fails silently with custom @Query annotations if you don't align them. I've seen teams spend hours debugging why their EntityGraph was ignored.

Finally, the docs rarely mention the impact on pagination. Using JOIN FETCH with Pageable can lead to in-memory pagination because Hibernate can't apply LIMIT correctly after joins. The result: your "page of 20" actually loads all rows into memory and then slices. That's a memory killer in production.

public interface OrderRepository extends JpaRepository<Order, Long> {

    // This works with EntityGraph
    @EntityGraph(attributePaths = {"items"})
    List<Order> findAll();

    // This IGNORES EntityGraph because of custom @Query
    @EntityGraph(attributePaths = {"items"})
    @Query("SELECT o FROM Order o WHERE o.customerName = :name")
    List<Order> findByCustomerName(@Param("name") String name);

    // Fix: include JOIN FETCH in the @Query
    @Query("SELECT o FROM Order o JOIN FETCH o.items WHERE o.customerName = :name")
    List<Order> findByCustomerNameFixed(@Param("name") String name);
}

Detecting N+1 with Hibernate Statistics

You can't fix what you can't measure. Hibernate provides a built-in Statistics API that logs query counts, cache hits, and flush times. Enable it in application.properties and watch the logs. I recommend enabling it in all environments except production, or selectively via a custom filter.

Here's how to set it up:

# Enable Hibernate statistics
spring.jpa.properties.hibernate.generate_statistics=true

# Log SQL statements (useful for debugging)
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.format_sql=true

# Log slow queries (threshold in ms)
spring.jpa.properties.hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS=100

# In production, use a logger level
logging.level.org.hibernate.stat=DEBUG
logging.level.org.hibernate.SQL=DEBUG

Fix #1: JOIN FETCH for Immediate Loading

The most straightforward fix is to use JOIN FETCH in your JPQL query. This tells Hibernate to load the association in the same SQL query using a JOIN. It's explicit, easy to understand, and works with pagination if you're careful (single collection only).

Let's fix our order repository:

public interface OrderRepository extends JpaRepository<Order, Long> {

    // Fix N+1 with JOIN FETCH
    @Query("SELECT DISTINCT o FROM Order o JOIN FETCH o.items")
    List<Order> findAllWithItems();

    // With pagination (works only if no multiple collections)
    @Query(value = "SELECT o FROM Order o JOIN FETCH o.items",
           countQuery = "SELECT COUNT(o) FROM Order o")
    Page<Order> findAllWithItemsPaged(Pageable pageable);

    // Filtered
    @Query("SELECT DISTINCT o FROM Order o JOIN FETCH o.items WHERE o.customerName = :name")
    List<Order> findByCustomerWithItems(@Param("name") String name);
}

Fix #2: Using @EntityGraph for Declarative Fetching

@EntityGraph is a JPA 2.1 feature that lets you define fetch strategies declaratively without writing JPQL. It's great for derived query methods (findByXxx) where you can't easily add JOIN FETCH. You define an entity graph on the entity or repository method.

Here's how to use it:

@Entity
@Table(name = "orders")
@NamedEntityGraph(name = "Order.withItems",
    attributeNodes = @NamedAttributeNode("items"))
public class Order {
    // ... fields
}

// Repository
public interface OrderRepository extends JpaRepository<Order, Long> {

    @EntityGraph("Order.withItems")
    List<Order> findByCustomerName(String name);

    // Dynamic graph via attribute paths
    @EntityGraph(attributePaths = {"items", "payments"})
    List<Order> findByStatus(String status);
}

Fix #3: Batch Fetching as a Safety Net

Sometimes you can't avoid lazy-loading — maybe you have deep object graphs or dynamic access patterns. Batch fetching tells Hibernate to load multiple collections in batches rather than one by one. You can configure it globally or per entity.

Batch fetching is not a silver bullet; it still generates multiple queries (N/batchSize + 1), but it reduces them significantly. For example, with batch size 20, 100 orders generate 1 + 5 queries instead of 101.

# Global batch fetching
spring.jpa.properties.hibernate.default_batch_fetch_size=20

# Or per entity
@Entity
@BatchSize(size = 20)
public class Order {
    // ...
}

Fix #4: DTO Projections to Avoid Entity Loading

The ultimate fix is to not load entities at all when you only need a subset of data. DTO projections with JPQL or constructor expressions let you fetch exactly the columns you need. This avoids lazy-loading entirely and reduces memory footprint.

For our invoice summary example, we only needed invoice number, customer name, and total items. No need to load the full LineItem entities.

public record InvoiceSummary(Long id, String invoiceNumber, String customerName, int itemCount) {}

// Repository
public interface InvoiceRepository extends JpaRepository<Invoice, Long> {

    @Query("""
        SELECT new com.example.dto.InvoiceSummary(
            i.id, i.invoiceNumber, i.customerName, 
            SIZE(i.lineItems)
        ) FROM Invoice i
    """)
    List<InvoiceSummary> findAllSummaries();

    // Or use constructor expression with JOIN for more complex
    @Query("""
        SELECT new com.example.dto.InvoiceLineItemDTO(
            i.id, i.invoiceNumber, li.productName, li.amount
        ) FROM Invoice i JOIN i.lineItems li
    """)
    List<InvoiceLineItemDTO> findAllWithLineItems();
}

Preventing N+1 with Spring Data JPA Specifications

When you need dynamic queries with filters, JOIN FETCH and @EntityGraph can become unwieldy. Spring Data JPA's Specification API combined with FetchStrategy can help, but you must be explicit about fetching. I recommend creating a custom repository base class that applies fetch joins based on annotations.

Alternatively, use QueryDSL or Blaze-Persistence for more sophisticated fetch control. But for most cases, a simple pattern with Specifications and a fetch utility works.

public class OrderSpecifications {

    public static Specification<Order> hasCustomerName(String name) {
        return (root, query, cb) -> {
            // Ensure fetch is applied only for non-count queries
            if (query.getResultType() != Long.class) {
                root.fetch("items", JoinType.LEFT);
            }
            return cb.equal(root.get("customerName"), name);
        };
    }
}

// Service
public List<Order> findOrdersWithItems(String name) {
    return orderRepository.findAll(
        OrderSpecifications.hasCustomerName(name)
    );
}