Hibernate One-to-Many & Many-to-Many: Stop Killing Your DB with Eager Fetch

If you've been writing Spring Boot applications with JPA and Hibernate for more than a week, you've probably run into the dreaded LazyInitializationException. Or worse, you've "fixed" it by slapping FetchType.EAGER on every association and watched your database crawl to a halt. I've seen both. I've debugged both. And I've cleaned up the mess from both in production systems processing millions of transactions a day.

In this article, we're going to cut through the noise. We'll cover Hibernate's One-to-Many and Many-to-Many mappings — the right way. We'll talk about why the default fetch strategies are dangerous, how N+1 queries sneak in, and what you should actually do instead. We'll use real-world examples from a payment-processing domain: invoices and line items, and products with categories. By the end, you'll know how to map these relationships without killing your database.

This isn't a beginner tutorial. I assume you know what an Entity is and have written a few repositories. We're going straight to the deep end: performance, pitfalls, and production patterns. If you're still using FetchType.EAGER on collections, prepare to have your mind changed.

The One-to-Many Mapping That Works

Let's start with the most common relationship: an Invoice has multiple LineItems. In a payment-processing system, this is bread and butter. The naive approach is to annotate Invoice with @OneToMany and LineItem with @ManyToOne, and call it a day. But that's how you end up with the incident above.

Here's the correct mapping for a production system. We use FetchType.LAZY on both sides, and we use a Set instead of a List for the collection. Why Set? Because Hibernate's handling of List collections can lead to duplicate entries and unexpected SQL updates when you add or remove items. With a Set, you get predictable behavior.

@Entity
@Table(name = "invoices")
public class Invoice {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String invoiceNumber;
    private BigDecimal totalAmount;
    private LocalDate issueDate;

    @OneToMany(mappedBy = "invoice", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true)
    @BatchSize(size = 50)
    private Set<LineItem> lineItems = new HashSet<>();

    // constructors, getters, setters

    public void addLineItem(LineItem item) {
        lineItems.add(item);
        item.setInvoice(this);
    }

    public void removeLineItem(LineItem item) {
        lineItems.remove(item);
        item.setInvoice(null);
    }
}

What the Official Docs Won't Tell You

The Hibernate documentation is technically correct but practically dangerous. It tells you that FetchType.EAGER is a valid strategy. It is — if you enjoy pager duty at 3 AM. The docs don't emphasize that EAGER loading on collections bypasses your ability to control query execution. Every time you load an entity with an EAGER collection, Hibernate will execute an additional query (or a join, if it can) regardless of whether you need that data.

The official docs also gloss over the fact that EAGER fetching on multiple collections in the same entity can result in Cartesian product joins. Imagine an Order with EAGER LineItems and EAGER Payments. If an order has 5 line items and 3 payments, Hibernate might execute a single query that returns 15 rows (5 * 3). That's a Cartesian product, and it's a performance disaster for even moderately sized datasets.

What the docs should say: "Use FetchType.LAZY for all collection mappings. If you need to eagerly load, use a specific JPQL query with JOIN FETCH. Never rely on the default fetch strategy for collections."

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

    // This is the correct way to eagerly load lineItems when needed
    @Query("SELECT i FROM Invoice i LEFT JOIN FETCH i.lineItems WHERE i.id = :id")
    Optional<Invoice> findByIdWithLineItems(@Param("id") Long id);

    // Without JOIN FETCH, this will trigger a LazyInitializationException if accessed outside a transaction
    Optional<Invoice> findById(Long id);
}

Many-to-Many: The Silent Performance Killer

Many-to-Many relationships are rare in well-designed schemas, but they exist. A common example: Products and Categories. A product can belong to many categories, and a category can contain many products. The naive JPA mapping uses @ManyToMany with a join table, and again, FetchType.EAGER is the default for the owning side. That's a trap.

In a real production system, the join table can grow to millions of rows. Loading a single product with FetchType.EAGER on categories will load all categories and all their products (if you have a bidirectional mapping). That's a cascade of queries that can bring down your database.

Here's the correct approach: use FetchType.LAZY, use Set (again), and avoid the bidirectional mapping if possible. If you need bidirectional access, use @ManyToMany(mappedBy = ...) on the inverse side with LAZY loading.

@Entity
@Table(name = "products")
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private BigDecimal price;

    @ManyToMany(fetch = FetchType.LAZY)
    @JoinTable(
        name = "product_categories",
        joinColumns = @JoinColumn(name = "product_id"),
        inverseJoinColumns = @JoinColumn(name = "category_id")
    )
    @BatchSize(size = 20)
    private Set<Category> categories = new HashSet<>();

    // constructors, getters, setters
}

The N+1 Query Problem: How to Detect and Fix It

The N+1 query problem is the most common performance issue in Hibernate applications. It occurs when you load a collection of parent entities and then access child collections for each parent, resulting in 1 query for the parents and N queries for the children. This is exactly what FetchType.EAGER does by default, but even with LAZY, you can trigger it if you access the children inside a loop.

Detection is straightforward: enable Hibernate statistics. Add spring.jpa.properties.hibernate.generate_statistics=true to your application.properties. Then monitor the logs for the number of queries executed per request. If you see 100 queries for 10 parents, you have an N+1 problem.

Fixing it requires either: 1. Using JOIN FETCH in your JPQL query to load children in a single query. 2. Using @BatchSize to batch the loading of children (reduces N+1 to N/50+1). 3. Using a DTO projection to avoid loading entities altogether.

The third option is often the best for read-heavy endpoints. Why load full entities when you only need a few fields?

@Service
public class InvoiceService {

    private final InvoiceRepository invoiceRepository;

    public InvoiceService(InvoiceRepository invoiceRepository) {
        this.invoiceRepository = invoiceRepository;
    }

    // BAD: triggers N+1 queries
    public List<InvoiceDTO> getAllInvoicesBad() {
        List<Invoice> invoices = invoiceRepository.findAll();
        List<InvoiceDTO> dtos = new ArrayList<>();
        for (Invoice invoice : invoices) {
            // This triggers a query for each invoice's lineItems
            Set<LineItem> items = invoice.getLineItems();
            dtos.add(new InvoiceDTO(invoice, items.size()));
        }
        return dtos;
    }

    // GOOD: uses JOIN FETCH to load everything in one query
    public List<InvoiceDTO> getAllInvoicesGood() {
        List<Invoice> invoices = invoiceRepository.findAllWithLineItems();
        return invoices.stream()
            .map(inv -> new InvoiceDTO(inv, inv.getLineItems().size()))
            .toList();
    }
}

Transaction Boundaries and LazyInitializationException

The LazyInitializationException is the second most common Hibernate pain point. It occurs when you try to access a lazy-loaded collection outside of an active Hibernate session (transaction). The knee-jerk reaction is to add @Transactional on every service method, but that's a band-aid, not a fix.

The real solution is to design your service layer to load all required data within a single transaction. If you need to return entities to the presentation layer, either: 1. Ensure the transaction is still open (using Open Session in View — which I don't recommend for production). 2. Convert entities to DTOs within the transactional method. 3. Use JOIN FETCH to pre-load the required associations.

The Open Session in View (OSIV) pattern is enabled by default in Spring Boot. It keeps the Hibernate session open during the entire request, allowing lazy loading in views. This is convenient but dangerous: it can lead to long-running database transactions, connection pool exhaustion, and unexpected queries. I've seen OSIV cause production outages because a slow template rendering kept the session open, holding a database connection for minutes.

@RestController
@RequestMapping("/api/invoices")
public class InvoiceController {

    private final InvoiceService invoiceService;

    public InvoiceController(InvoiceService invoiceService) {
        this.invoiceService = invoiceService;
    }

    // This will throw LazyInitializationException if lineItems are accessed outside the transaction
    @GetMapping("/{id}")
    public Invoice getInvoice(@PathVariable Long id) {
        return invoiceService.findById(id);
    }

    // Correct approach: return a DTO
    @GetMapping("/{id}/with-items")
    public InvoiceDTO getInvoiceWithItems(@PathVariable Long id) {
        return invoiceService.findByIdWithLineItems(id);
    }
}

Cascade Operations: When to Use and When to Avoid

Cascade operations in Hibernate are convenient but dangerous. They automate the propagation of entity state changes to associated entities. For One-to-Many, CascadeType.ALL is common because you typically want to save, update, and delete line items with their invoice. But for Many-to-Many, cascading is almost always wrong.

Consider a Product with Categories. If you cascade PERSIST from Product to Category, creating a new product with a new category will try to persist the category. But what if that category already exists? You'll get a constraint violation. Worse, if you cascade REMOVE, deleting a product will delete its categories — which are likely shared with other products. That's a data integrity disaster.

Best practice: For @OneToMany, use CascadeType.ALL or CascadeType.PERSIST + CascadeType.MERGE. For @ManyToMany, use NO cascade. Manage the join table explicitly through the owning entity's collection.

@Entity
@Table(name = "categories")
public class Category {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    // No cascade here! The inverse side should not cascade anything.
    @ManyToMany(mappedBy = "categories", fetch = FetchType.LAZY)
    private Set<Product> products = new HashSet<>();

    // constructors, getters, setters
}

Performance Tuning: Batch Fetching and Pagination

Even with FetchType.LAZY, accessing child collections for multiple parents can still result in many queries. That's where batch fetching comes in. @BatchSize tells Hibernate to load multiple child collections in a single query when you access them. For example, with @BatchSize(size = 50), accessing lineItems for 100 invoices will result in 2 queries instead of 100.

But batch fetching has a caveat: it only works when you access the collection lazily. If you use JOIN FETCH, batch size is ignored. Also, batch fetching can lead to unpredictable query patterns if the batch size is too large. A size of 100 might load 100 collections in one query, which could be a massive join.

For pagination, never use JOIN FETCH on a collection when using Pageable. Hibernate will load all entities into memory and then apply pagination in memory, defeating the purpose. Instead, use a two-step approach: first, get the IDs of the parent entities using a count query and a limit query. Then, fetch the parents with their children using a separate query with WHERE id IN (:ids).

@Repository
public interface InvoiceRepositoryPagination extends JpaRepository<Invoice, Long> {

    // Step 1: Get IDs for the page
    @Query("SELECT i.id FROM Invoice i WHERE i.issueDate BETWEEN :start AND :end ORDER BY i.issueDate")
    Page<Long> findIdsByIssueDateBetween(@Param("start") LocalDate start, @Param("end") LocalDate end, Pageable pageable);

    // Step 2: Fetch full entities with children for those IDs
    @Query("SELECT i FROM Invoice i LEFT JOIN FETCH i.lineItems WHERE i.id IN :ids")
    List<Invoice> findByIdsWithLineItems(@Param("ids") List<Long> ids);
}

Testing Hibernate Associations: What to Watch For

Testing Hibernate associations is tricky because the behavior changes between a test environment (small datasets, in-memory database) and production (large datasets, real database). You can't trust that a test passing with H2 means it will work in PostgreSQL with 10 million rows.

The key things to test: 1. Query count: Use Hibernate statistics in tests to assert that a specific operation executes exactly N queries. If your test expects 1 query but executes 100, you have an N+1 problem. 2. Lazy loading behavior: Ensure that accessing a lazy collection outside a transaction throws LazyInitializationException. This proves your code is correctly scoped. 3. Cascade behavior: Test that deleting a parent cascades correctly to children (or doesn't, depending on your mapping). 4. Join fetch correctness: Test that your JOIN FETCH queries return the expected number of rows, especially when there are multiple collections.

Use Testcontainers with a real PostgreSQL database for integration tests. H2 is fine for repository unit tests, but it doesn't replicate PostgreSQL's query planner behavior.

@SpringBootTest
@Testcontainers
class InvoiceServiceTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15")
        .withDatabaseName("testdb")
        .withUsername("test")
        .withPassword("test");

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
        registry.add("spring.jpa.properties.hibernate.generate_statistics", () -> "true");
    }

    @Autowired
    private InvoiceService invoiceService;

    @Autowired
    private TestEntityManager entityManager;

    @Test
    void shouldNotCauseNPlusOne() {
        // Given: 10 invoices each with 3 line items
        for (int i = 0; i < 10; i++) {
            Invoice invoice = new Invoice();
            for (int j = 0; j < 3; j++) {
                invoice.addLineItem(new LineItem());
            }
            entityManager.persist(invoice);
        }
        entityManager.flush();
        entityManager.clear();

        // When: accessing all invoices with line items count
        List<InvoiceDTO> dtos = invoiceService.getAllInvoicesGood();

        // Then: exactly 1 query should be executed
        assertThat(dtos).hasSize(10);
        // Use a custom assertion or log to verify query count
    }
}