skip to content

When would you choose @EntityGraph over a JPQL JOIN FETCH, @BatchSize, or a DTO projection?

level: principalimportance: should knowfreq 40%

answer

  1. EntityGraph = declarative on derived/@Query methods
  2. JOIN FETCH = imperative inline JPQL
  3. @BatchSize = pagination-safe batched IN loads
  4. projection = read-only, few columns, no entity
  5. collection joins -> cartesian; batch/projection avoid it

basics

~20 s

Use @EntityGraph for a declarative eager plan on derived/named repository methods without writing JPQL. Use JOIN FETCH when you already write custom JPQL. Use @BatchSize when you page collections or fetch several to-many sides. Use DTO projections when you only need a few fields read-only.

solid answer

~50 s

They are complementary tools for controlling fetching. **@EntityGraph** is declarative and query-method-friendly: it layers an eager fetch plan onto **derived queries** (`findByStatus`) or named/custom queries without hand-writing joins, and it composes with `@Query`. Reach for it when you want reusable, mapping-adjacent fetch plans. **JPQL `JOIN FETCH`** is imperative — natural when you're already writing `@Query` JPQL and want the join inline (and lets you add `DISTINCT`, `WHERE`, ordering in one place). **`@BatchSize`** (or `hibernate.default_batch_fetch_size`) doesn't join at all; it keeps associations LAZY and loads them in a few batched `IN` queries — the right tool when **paginating** collections or when a join would explode into a cartesian product. **DTO/interface projections** skip entities entirely, selecting only needed columns read-only — best for list/read screens where you never mutate. Principal-level judgement: entity graphs and join fetch build managed entity graphs (writable, first-level-cache) but risk cartesian blow-ups; batch fetching and projections scale better for large or paginated reads. Pick per use case, not one global strategy.

code

java · 15 lines
java
public interface AuthorRepository extends JpaRepository<Author, Long> {

    // @EntityGraph on a derived query: declarative, reusable, mapping stays LAZY
    @EntityGraph(attributePaths = "books")
    List<Author> findByActiveTrue();

    // JOIN FETCH: imperative, combine fetch + filter + distinct in one JPQL
    @Query("select distinct a from Author a join fetch a.books where a.active = true")
    List<Author> findActiveWithBooks();

    // Projection: read-only list screen, no entities hydrated
    @Query("select a.name as name, count(b) as bookCount "
         + "from Author a left join a.books b group by a.id, a.name")
    List<AuthorView> listAuthorSummaries();
}

go deeper

for a junior

Know the four tools exist and that @EntityGraph avoids writing JPQL joins.

for a middle

Explain JOIN FETCH vs @EntityGraph equivalence and when @BatchSize helps with pagination.

for a senior

Match each tool to a use case, including projections for read-only screens and batch-size for cartesian avoidance.

for a principal

Reason about managed-entity overhead, cartesian blow-ups, centralizing fetch intent, and profiling-driven, per-path strategy rather than one global approach.

### The toolbox for fetch tuning All four solve 'load associated data efficiently', but with different trade-offs. **1. `@EntityGraph`** — declarative, Spring-Data-native. - Adds an eager fetch plan (via the `fetchgraph`/`loadgraph` hint) to a repository method — works on **derived** queries (`findByEmail`), **named** graphs, and on top of `@Query`. - Pros: no hand-written joins; reusable named graphs; keeps mappings LAZY; reads naturally on the repository interface. - Cons: same collection-join hazards as JOIN FETCH (MultipleBagFetchException, in-memory pagination, cartesian products); returns **managed** entities (memory + dirty-checking cost). **2. JPQL `JOIN FETCH`** — imperative, inline in `@Query`. ```java @Query("select distinct a from Author a join fetch a.books where a.active = true") List<Author> findActiveWithBooks(); ``` - Pros: full control in one statement — combine the fetch with `WHERE`, `ORDER BY`, `DISTINCT`; obvious to readers of the JPQL. - Cons: you write and maintain the JPQL; duplicating joins across methods; same collection caveats. Good when the query is already custom. **3. `@BatchSize` / `hibernate.default_batch_fetch_size`** — batched lazy loading, no join. ```java @OneToMany(mappedBy = "author") @BatchSize(size = 25) private Set<Book> books; ``` - Keeps the association LAZY; when the first proxy is initialized, Hibernate loads up to N of them in one `... where author_id in (?, ?, ...)` query. N+1 becomes ceil(N/size)+1. - Pros: **pagination-safe** (root query is unaffected), avoids cartesian products, great for multiple to-many sides. - Cons: still multiple round trips (though few); requires an open session when the proxy is touched. **4. DTO / interface projections** — no entities at all. ```java interface AuthorView { String getName(); long getBookCount(); } @Query("select a.name as name, count(b) as bookCount from Author a left join a.books b group by a.id, a.name") List<AuthorView> listAuthors(); ``` - Pros: selects only needed columns; read-only and cheap; no lazy-loading traps; ideal for list/table screens and aggregates. - Cons: not managed/writable; you maintain the projection shape; can't navigate the object graph freely. ### Decision guide - **Need managed entities you'll modify, plus one association** -> `@EntityGraph` (or `JOIN FETCH` if already custom JPQL). - **Already writing custom JPQL / need WHERE+fetch together** -> `JOIN FETCH`. - **Paginating a collection, or several to-many associations** -> `@BatchSize` / `default_batch_fetch_size` (keep LAZY, batch load). - **Read-only list/report, only a few fields** -> DTO/interface projection (fastest, most scalable). ### Deeper considerations (principal lens) - **Cartesian products**: both `@EntityGraph` and `JOIN FETCH` on collections multiply rows; batching and projections avoid that. - **Managed vs detached cost**: entity fetches hydrate the persistence context (dirty checking, memory). Projections avoid this overhead entirely for read paths — meaningful at scale. - **Consistency & maintainability**: named entity graphs centralize fetch intent; scattering JOIN FETCH everywhere duplicates logic. But entity graphs hide the SQL, which can surprise. Choose per team and per hot path — profile with query counters, don't guess. - **Not mutually exclusive**: a common pattern is entity graph for the write/detail path, batch-size for incidental collections, projections for list screens — layered, not one-size-fits-all.

  • Your list endpoint paginates authors and needs each author's book count and a couple of fields. Which tool and why?
    A DTO/interface projection with an aggregate query. It selects only needed columns, is read-only (no persistence-context overhead), paginates cleanly in SQL, and sidesteps every collection-join and lazy-loading hazard.
  • Can you combine @EntityGraph with a custom @Query?
    Yes. Spring applies the entity graph as a fetch hint on top of the @Query JPQL. It's a common way to keep a hand-written WHERE while declaring the fetch plan separately.

saying these in an interview costs you the question

  • Claiming @EntityGraph and JOIN FETCH are fundamentally different fetch mechanisms (both build a join-based fetch plan)
  • Recommending eager join fetching for large paginated list screens instead of projections/batching
  • Believing @BatchSize eliminates all extra queries (it batches them, doesn't remove them)

context

resolving links…