Tired of N+1 Queries? Boost Your Spring Boot GraphQL Performance 40× with DataLoader

When a GraphQL client requests a list of books and each book's author, a naive implementation issues one SQL query for the books and an additional query for each author, resulting in N+1 queries (e.g., 1,011 queries for 1,000 books) and severe performance degradation.

DataLoader solves this by collecting individual load requests, delaying execution briefly, and then issuing a single batch query; the results are distributed back to the original CompletableFuture objects. The core workflow is illustrated as a collect‑delay‑batch diagram.

The simplified Java implementation of DataLoader maintains a Queue<K> keyQueue and a list of pending CompletableFuture<V> objects, schedules batch loading after a configurable delay, and on execution calls the provided batch loader to fetch all keys at once, completing each future with the corresponding result.

DataLoader also includes two levels of caching: futureCache stores in‑flight futures to avoid duplicate loads for the same key, while valueCache stores the final values for subsequent identical requests.

Integration steps for a Spring Boot project are shown: add spring-boot-starter-web, spring-boot-starter-graphql, and JPA dependencies in build.gradle; define the GraphQL schema with Book and Author types; create JPA entity classes and repositories for both tables.

Batch loaders are registered via BatchLoaderRegistry. The author loader collects author IDs, performs a single findAllById call, builds a Map<Long, Author>, and returns a completed future. The books‑by‑author loader similarly batches author IDs, fetches all related books with findByAuthorIdIn, groups them by author ID, and returns a map. Query mapping methods use @SchemaMapping with @Name("authorLoader") and @Name("booksByAuthorLoader") to obtain the appropriate DataLoader and invoke load.

Two batch‑loader return styles are compared: BatchLoader must return a List whose order matches the input IDs, while MappedBatchLoader returns a Map and is recommended because it avoids ordering pitfalls. Code snippets illustrate both approaches.

The article also includes diagrams comparing the two modes and highlights common mistakes such as mismatched return types, forgetting to preserve order, and improper use of @BatchMapping versus @SchemaMapping.