JPA vs Hibernate: The N+1 Query That Destroyed Our Dashboard Performance

In 2023, our SaaS billing dashboard at a mid-size fintech company started timing out. The dashboard showed monthly revenue per customer — 12,000 customers, 3 years of data. Simple right? We used Spring Boot 3.2 with Spring Data JPA 3.2 and Hibernate 6.4. The dashboard query took 45 seconds. The root cause? N+1 query problem disguised as "just using JPA." Many developers treat JPA and Hibernate as interchangeable. They're not. JPA is a specification — a contract. Hibernate is the most popular implementation. But the abstraction leaks. When you write List<Invoice> findByCustomerId(Long id), JPA doesn't care about performance. Hibernate decides how to fetch data. And Hibernate's default lazy loading is the culprit. Our team assumed "JPA handles performance" — wrong. We had to dig into Hibernate-specific features like @BatchSize, JOIN FETCH, and @EntityGraph to fix it. This article is a war story with code, metrics, and lessons from production. You'll learn the exact difference between JPA and Hibernate, how N+1 queries destroy performance, and how to debug them in production without guesswork.

The Real Difference Between JPA and Hibernate

JPA (Java Persistence API) is a specification defined in JSR 338 (Java EE 7) and later in Jakarta Persistence 3.1. It defines interfaces like EntityManager, annotations like @Entity, and query language JPQL. Hibernate is the most popular implementation of JPA, but it's not the only one (EclipseLink, OpenJPA exist). The critical distinction: JPA doesn't dictate how queries are executed. When you call customer.getInvoices(), JPA doesn't specify whether it should be lazy or eager — that's Hibernate's decision. In Spring Data JPA 3.x, the default fetch type for @OneToMany is LAZY. But "lazy" doesn't mean no query — it means "query on access." So when you access customer.getInvoices() in a loop, Hibernate fires one SQL per customer. That's N+1. Hibernate 6.4 introduced improved batch fetching with @BatchSize, but it's not enabled by default. The JPA spec has no concept of batch fetching — it's purely Hibernate. So when someone says "JPA is slow," they usually mean "Hibernate's default configuration is slow." Understanding this distinction is the first step to fixing performance.

@Repository
public interface CustomerRepository extends JpaRepository<Customer, Long> {
    // JPA method - triggers N+1
    List<Customer> findAll();

    // Hibernate-specific fix with JOIN FETCH
    @Query("SELECT c FROM Customer c JOIN FETCH c.invoices")
    List<Customer> findAllWithInvoices();

    // Alternative: EntityGraph (JPA 2.1+)
    @EntityGraph(attributePaths = {"invoices"})
    @Query("SELECT c FROM Customer c")
    List<Customer> findAllWithInvoicesEntityGraph();
}

What the Official Docs Won't Tell You

The official Spring Data JPA documentation shows clean examples with List findAll(). It works fine for 10 customers. For 10,000, it's a disaster. The docs mention lazy loading but don't emphasize that iterating over a lazy collection triggers N queries. They also don't tell you that @OneToMany defaults to LAZY only since Spring Data JPA 2.0 (before that it was EAGER). Many legacy codebases still have EAGER from older versions, which causes different performance issues (loading everything upfront). The official Hibernate docs show @BatchSize but don't warn that it only works with Hibernate's session, not with Spring Data JPA's repository methods directly. You need to call Hibernate.initialize() or use JOIN FETCH explicitly. Another hidden detail: @EntityGraph (JPA 2.1+) works but only if the query doesn't use pagination. If you use Pageable with @EntityGraph, Hibernate might load all entities into memory first, then paginate — defeating the purpose. The docs also don't mention that hibernate.query.passDistinctThrough=true (Hibernate 6.4) can reduce duplicate rows when using JOIN FETCH with collections. These are the real-world gotchas that cost hours of debugging.

spring:
  jpa:
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        # Enable query statistics for production monitoring
        generate_statistics: true
        # Avoid duplicates with JOIN FETCH
        query.passDistinctThrough: true
        # Batch fetching size
        default_batch_fetch_size: 50

How to Reproduce N+1 in Spring Boot 3.2

Let's create a minimal Spring Boot 3.2 project with two entities: Customer and Invoice. The Customer has a @OneToMany relationship to Invoice. By default, this is lazy. Write a service method that calls customerRepository.findAll() and then iterates over customers to get invoices. Enable SQL logging with spring.jpa.show-sql=true. Run it with 100 customers, each with 5 invoices. You'll see 1 query for customers, then 100 queries for invoices — 101 total. That's N+1. Now add a @Query("SELECT c FROM Customer c JOIN FETCH c.invoices") method. Run again: 1 query with a JOIN. For 100 customers, that's 1 query vs 101. For 12,000, it's 1 vs 12,001. The reproduction is straightforward but the impact is exponential. Use spring.jpa.properties.hibernate.generate_statistics=true to see the exact query count in logs. This is the first thing you should do in any new project to establish a baseline.

@Service
public class DashboardService {
    private final CustomerRepository customerRepo;

    public DashboardService(CustomerRepository customerRepo) {
        this.customerRepo = customerRepo;
    }

    // This method triggers N+1
    public List<Customer> getCustomersWithInvoices() {
        List<Customer> customers = customerRepo.findAll(); // 1 query
        for (Customer c : customers) {
            c.getInvoices().size(); // N queries - one per customer
        }
        return customers;
    }

    // This method uses JOIN FETCH
    public List<Customer> getCustomersWithInvoicesOptimized() {
        return customerRepo.findAllWithInvoices(); // 1 query with JOIN
    }
}

JOIN FETCH vs @EntityGraph: Which One to Use?

Both JOIN FETCH and @EntityGraph solve N+1 by fetching associated entities in a single query. But they differ in execution and flexibility. JOIN FETCH is a JPQL hint that forces Hibernate to use an SQL JOIN. It's explicit and works with any query. @EntityGraph is a JPA 2.1 feature that defines a graph of attributes to fetch. It's more declarative and can be reused. However, @EntityGraph has a catch: with @OneToMany, it uses a SQL JOIN internally, but if you use pagination (Pageable), Hibernate loads all matching rows into memory, then applies pagination in Java. This defeats the purpose. JOIN FETCH with pagination is also problematic — Hibernate throws a QueryException if you use setFirstResult/setMaxResults with JOIN FETCH on a collection. The workaround is to use @BatchSize or two queries: one for IDs, one for data. In production, we use JOIN FETCH for non-paginated queries and @BatchSize for paginated ones. @EntityGraph is cleaner for complex graphs (e.g., fetch invoices and invoice items), but test it with pagination first.

@Repository
public interface CustomerRepository extends JpaRepository<Customer, Long> {
    // JOIN FETCH - explicit, works with @Query
    @Query("SELECT c FROM Customer c JOIN FETCH c.invoices")
    List<Customer> findAllWithJoinFetch();

    // EntityGraph - declarative, JPA 2.1+
    @EntityGraph(attributePaths = {"invoices"})
    @Query("SELECT c FROM Customer c")
    List<Customer> findAllWithEntityGraph();

    // EntityGraph with pagination - loads all into memory!
    @EntityGraph(attributePaths = {"invoices"})
    @Query("SELECT c FROM Customer c")
    Page<Customer> findAllWithEntityGraphPaged(Pageable pageable);

    // Workaround: @BatchSize on entity
    // Customer entity: @BatchSize(size = 50)
    Page<Customer> findAll(Pageable pageable); // Lazy but batched
}

Debugging N+1 in Production with Hibernate 6.4

You can't always enable show-sql in production — it floods logs and leaks data. Instead, use Hibernate 6.4's query statistics. Set spring.jpa.properties.hibernate.generate_statistics=true in application-prod.yml. This logs a summary at the end of each session: number of queries, time, and entities loaded. For real-time monitoring, expose these metrics via Spring Boot Actuator 3.2. Create a custom health indicator that counts queries per request. If a single request fires more than 10 queries, log a warning. Another technique: use HibernateSessionEventListener to intercept queries. This is advanced but gives you per-request query counts. In our incident, we added a custom filter that logged the query count for each HTTP request. When we saw 12,001 queries for the dashboard endpoint, we knew immediately. The fix was to add JOIN FETCH. For ongoing monitoring, use hibernate.query.plan_cache_max_size to avoid plan cache bloat, and set hibernate.query.plan_parameter_metadata_max_size to limit metadata. These settings prevent memory leaks from dynamic queries.

@Component
public class QueryCountFilter implements Filter {
    private static final ThreadLocal<Integer> queryCount = new ThreadLocal<>();

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        queryCount.set(0);
        chain.doFilter(request, response);
        int count = queryCount.get();
        if (count > 10) {
            log.warn("N+1 detected for {}: {} queries", 
                ((HttpServletRequest) request).getRequestURI(), count);
        }
        queryCount.remove();
    }

    // Register with Hibernate session
    @EventListener
    public void handleSessionOpen(SessionFactoryOpenEvent event) {
        // Implementation to count queries per session
    }
}

Batch Fetching: The Unsung Hero of Hibernate 6.4

@BatchSize is a Hibernate annotation that groups lazy loads into batches. Instead of firing one query per entity, Hibernate fires one query per batch. For example, with @BatchSize(size = 50), accessing customer.getInvoices() for 100 customers triggers 2 queries instead of 100. This is especially useful for paginated queries where JOIN FETCH doesn't work. In Hibernate 6.4, you can set hibernate.default_batch_fetch_size globally in application.yml. This applies to all lazy collections. But beware: batch fetching still generates multiple SQL queries (N/batch + 1). For 12,000 customers with batch size 50, that's 241 queries. Better than 12,001, but not as good as 1 query with JOIN FETCH. Use batch fetching when you can't use JOIN FETCH (e.g., pagination) or when you have deep object graphs. Also, @BatchSize works on both entity level and collection level. For our dashboard, we added @BatchSize(size = 100) on the invoices collection and kept the paginated query. The dashboard loaded in 1.2 seconds — acceptable for a non-real-time report.

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

    private String name;

    @OneToMany(mappedBy = "customer", fetch = FetchType.LAZY)
    @BatchSize(size = 100)  // Hibernate-specific
    private List<Invoice> invoices = new ArrayList<>();

    // getters and setters
}

// Global config in application.yml
// spring.jpa.properties.hibernate.default_batch_fetch_size: 50

The Hidden Cost of Hibernate's First-Level Cache

Hibernate's first-level cache (persistence context) is per session. It caches entities by ID. In theory, this should reduce queries. In practice, it can mask N+1 during development. When you iterate over customers and access invoices, Hibernate checks the cache first. If the same invoice is referenced by multiple customers, it's fetched once. But in our billing system, each customer had unique invoices — no cache hits. The cache also grows with each entity loaded. For 12,000 customers with 5 invoices each, that's 72,000 entities in the persistence context. This causes memory pressure and slows down dirty checking at flush time. The fix: use read-only queries for dashboards. Add @Transactional(readOnly = true) on the service method. This disables dirty checking and reduces memory overhead. Also, clear the entity manager after processing: entityManager.clear(). In Hibernate 6.4, you can set hibernate.jpa.compliance.query=true to enforce stricter JPA compliance, but it disables some Hibernate optimizations. For our dashboard, we used @Transactional(readOnly = true) and saw a 30% reduction in memory usage.

@Service
@Transactional(readOnly = true)  // Disables dirty checking
public class DashboardService {
    private final CustomerRepository customerRepo;
    private final EntityManager entityManager;

    public DashboardService(CustomerRepository customerRepo, EntityManager entityManager) {
        this.customerRepo = customerRepo;
        this.entityManager = entityManager;
    }

    public List<DashboardRow> getDashboardData() {
        List<Customer> customers = customerRepo.findAllWithInvoices();
        List<DashboardRow> rows = new ArrayList<>();
        for (Customer c : customers) {
            rows.add(new DashboardRow(c.getId(), c.getName(), 
                c.getInvoices().stream().mapToDouble(Invoice::getAmount).sum()));
        }
        entityManager.clear();  // Frees first-level cache
        return rows;
    }
}

Future-Proofing: JPA 3.1 and Hibernate 6.4 Best Practices

Jakarta Persistence 3.1 (JPA 3.1) introduced @Find and @Query enhancements, but the N+1 problem remains. Hibernate 6.4 added hibernate.query.passDistinctThrough and improved batch fetching, but the core issue is developer awareness. Here's our production checklist: 1) Enable hibernate.generate_statistics in staging. 2) Use JOIN FETCH or @EntityGraph for all read endpoints that return collections. 3) Set default_batch_fetch_size: 50 globally. 4) Use @Transactional(readOnly = true) on all read services. 5) Add a custom filter to log query counts per request. 6) Test with realistic data volumes (at least 10x expected). 7) Use Hibernate 6.4's @Nationalized for string columns to avoid N+1 on character encoding. 8) Avoid findAll() without pagination in any production endpoint. 9) Use projections (interface or DTO) for read-only data instead of full entities. 10) Monitor with Spring Boot Actuator 3.2 metrics. These practices saved us from two more N+1 incidents in the following months. The key is to treat N+1 as a design issue, not a bug — it's inherent in ORM and requires proactive prevention.

// Interface-based projection (Spring Data JPA)
public interface CustomerInvoiceSummary {
    Long getId();
    String getName();
    Double getTotalInvoiceAmount();
}

@Repository
public interface CustomerRepository extends JpaRepository<Customer, Long> {
    // No N+1 because it's a single query with aggregation
    @Query("SELECT c.id AS id, c.name AS name, SUM(i.amount) AS totalInvoiceAmount " +
           "FROM Customer c LEFT JOIN c.invoices i GROUP BY c.id, c.name")
    List<CustomerInvoiceSummary> findCustomerSummaries();
}

// DTO projection (JPQL)
public record CustomerDto(Long id, String name, Double totalInvoiceAmount) {}

@Query("SELECT new com.example.dto.CustomerDto(c.id, c.name, SUM(i.amount)) " +
       "FROM Customer c LEFT JOIN c.invoices i GROUP BY c.id, c.name")
List<CustomerDto> findCustomerDtoSummaries();