The @ManyToOne Tax and Bidirectional Mapping Overhead

@ManyToOne defaults to FetchType.EAGER. Not LAZY. Read that again. Every @ManyToOne in your codebase loads its parent entity immediately, whether you need it or not. The JPA specification chose EAGER as the default for to-one associations because it assumed you usually need the parent when you load the child. In practice, this assumption costs you queries on every single entity load.

The Lie

@ManyToOne is a lightweight reference to a parent entity. It loads only what you need.

The Reality

@ManyToOne with the default EAGER fetch eagerly loads the parent entity with a JOIN or a secondary SELECT. If that parent entity has its own EAGER @ManyToOne, Hibernate follows the chain. You can load an OrderItem, which loads its Order, which loads its Customer, which loads its CustomerGroup, each adding either a JOIN or a secondary query.

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

    private String productName;

    // BAD: default EAGER
    @ManyToOne
    @JoinColumn(name = "order_id")
    private Order order;
}

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

    // BAD: default EAGER
    @ManyToOne
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

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

    private String name;

    // BAD: default EAGER
    @ManyToOne
    @JoinColumn(name = "customer_group_id")
    private CustomerGroup group;
}

Loading a list of OrderItem entities via JPQL:

// BAD: Cascading EAGER fetches
List<OrderItem> items = entityManager
    .createQuery("SELECT i FROM OrderItem i", OrderItem.class)
    .getResultList();

// Generated SQL:
// select i1_0.id, i1_0.product_name, i1_0.order_id from order_items i1_0
// select o1_0.id, o1_0.customer_id from orders o1_0 where o1_0.id=?
// select c1_0.id, c1_0.name, c1_0.customer_group_id from customers c1_0 where c1_0.id=?
// select cg1_0.id, cg1_0.name from customer_groups cg1_0 where cg1_0.id=?
// select o1_0.id, o1_0.customer_id from orders o1_0 where o1_0.id=?
// select c1_0.id, c1_0.name, c1_0.customer_group_id from customers c1_0 where c1_0.id=?
// ... cascading for every unique parent in the result set

You queried for order items. You got order items, orders, customers, and customer groups. The persistence context deduplicates entities by primary key, so if multiple items share the same order, Hibernate only fetches that order once. But the first time each unique parent is encountered, a query fires.

The Fix

Make every @ManyToOne explicitly LAZY.

// BETTER: Explicit LAZY on all @ManyToOne
@Entity
public class OrderItem {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String productName;

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

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

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

With LAZY, loading OrderItem entities produces exactly one query. If you need the associated Order, use JOIN FETCH in your query.

A project-wide rule: grep your codebase for @ManyToOne without an explicit fetch = FetchType.LAZY. Every one you find is a potential hidden query chain.

# Find all @ManyToOne without explicit LAZY
grep -rn "@ManyToOne" --include="*.java" | grep -v "FetchType.LAZY"

Bidirectional Mapping Overhead

Bidirectional mappings (@OneToMany on the parent, @ManyToOne on the child) do not cause additional queries by themselves. The problem is consistency management.

// BAD: Inconsistent bidirectional state
Order order = new Order();
OrderItem item = new OrderItem();
item.setOrder(order);
// order.getItems() does NOT contain item unless you add it manually

entityManager.persist(order);
entityManager.persist(item);
// The foreign key is set correctly in the database because @ManyToOne owns the relationship.
// But in memory, order.getItems() is empty until you refresh or reload.

The fix: always synchronize both sides, or do not map the @OneToMany side at all.

// BETTER: Synchronization helper on the parent
@Entity
public class Order {
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
    private List<OrderItem> items = new ArrayList<>();

    public void addItem(OrderItem item) {
        items.add(item);
        item.setOrder(this);
    }

    public void removeItem(OrderItem item) {
        items.remove(item);
        item.setOrder(null);
    }
}

// BETTER: Drop the @OneToMany side entirely if you only navigate parent-to-child via queries
@Entity
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    // No items collection. Query for items when you need them.
}

// In the repository:
@Query("SELECT i FROM OrderItem i WHERE i.order.id = :orderId")
List<OrderItem> findItemsByOrderId(@Param("orderId") Long orderId);

Removing the @OneToMany side eliminates the proxy, eliminates the potential N+1, and forces all child loading to be explicit. The cost: you cannot cascade operations from parent to children, and you lose the convenience of order.getItems(). Whether that trade-off is worthwhile depends on how many different queries access the children.

The Cost Model

For an entity with three @ManyToOne associations, all defaulting to EAGER:

• Loading 1 entity via find(): 1 query with 3 JOINs (acceptable)
• Loading 100 entities via JPQL: 1 + up to 300 additional SELECT queries
• With all three set to LAZY: 1 query

The per-query cost of each unnecessary EAGER fetch is 0.5-2ms on a local database, 5-20ms on a remote database. With 100 entities and 3 EAGER associations, worst case is 300 * 20ms = 6 seconds of pure network overhead.

Making @ManyToOne LAZY is the single highest-impact change you can make to an existing Hibernate codebase. It costs nothing. It breaks nothing (except code that accesses the association outside a transaction, which is already a bug). Do it today.