Spring Data JPA lets an application work with JPA entities through repository interfaces instead of writing routine data-access implementations by hand. You define the entities and repository methods; Spring Data supplies the repository implementation and supports derived or declared queries, pagination, sorting, and other persistence features.
How Spring Data JPA fits into an application
Spring Data JPA is Spring’s repository-oriented persistence module for JPA. Its repository abstraction is designed to reduce boilerplate in data-access layers while keeping JPA entities and queries at the center of persistence. The official Spring Data JPA reference describes that goal, and the Spring Data JPA project page lists capabilities including CRUD operations, dynamic query generation, pagination, auditing, Querydsl integration, and custom data-access code.
- Entity model: JPA entities represent the persistent domain data.
- Repository interface: Your application declares an interface for an entity and its identifier type.
- Query method: A method name can describe a predicate, or you can declare a query explicitly.
- Infrastructure: Spring Data connects repository calls to JPA and supports features such as transactions, sorting, pagination, auditing, and locking.
Spring supplies the repository implementation at runtime; you normally write the interface rather than an implementation class. The Spring Data JPA project repository is the project’s codebase.
Create an entity and repository
For example, a customer entity can be paired with a repository whose identifier type matches the entity’s ID type:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11#1 Best Overall
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
@Entity
public class Customer {
@Id
@GeneratedValue
private Long id;
private String firstname;
private String lastname;
protected Customer() {}
public Customer(String firstname, String lastname) {
this.firstname = firstname;
this.lastname = lastname;
}
}import org.springframework.data.jpa.repository.JpaRepository;
public interface CustomerRepository extends JpaRepository<Customer, Long> {
}Extending JpaRepository<Customer, Long> gives the application the standard repository operations for Customer records, along with the JPA repository facilities. The interface can then declare domain-specific query methods. Spring Initializr is the project bootstrap route linked from the official project page; check that the Spring Boot and Java versions selected for a new application are compatible with the Spring Data JPA release you intend to use.
How query methods are derived from names
Spring Data interprets a repository method’s subject and predicate, separated by By. Predicate property names can be combined with And or Or; supported operators include comparisons such as Between, LessThan, GreaterThan, and Like. Static ordering can be expressed with OrderBy, while a method can accept a Sort for dynamic ordering.
public interface CustomerRepository extends JpaRepository<Customer, Long> {
List<Customer> findByLastnameAndFirstname(String lastname, String firstname);
List<Customer> findByLastnameOrderByFirstnameAsc(String lastname);
}These names make simple predicates discoverable where they are declared. Consult the query-method reference for the supported subject, predicate, operator, and result forms. Long or nested expressions can become difficult to understand; a method name is not automatically clearer just because it avoids a query annotation.
When to use @Query instead
Spring Data’s documented default lookup strategy is CREATE_IF_NOT_FOUND: it first looks for a declared query and, if it finds none, attempts to derive one from the method name. This lets a repository keep short, stable predicates as method names while giving more involved queries an explicit definition.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Approach | Useful when | Trade-off |
|---|---|---|
| Derived method | The predicate is short, stable, and readable as a method name. | A long expression can obscure what the query is meant to do. |
@Query |
You want to write a declared query explicitly, including a more involved query shape. | The query is now a separately maintained part of the repository contract. |
| Specifications, Querydsl, or a custom repository | Filters are dynamic, query construction is complex, or database-specific behavior needs an isolated implementation. | These options add design and implementation choices; use them when they solve a real readability or capability problem. |
For example, this declared JPQL query selects customers by last name without encoding the predicate in the method name:
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;
public interface CustomerRepository extends JpaRepository<Customer, Long> {
@Query("select c from Customer c where c.lastname = :lastname")
List<Customer> findCustomersByLastname(@Param("lastname") String lastname);
}Choose based on readability, query shape, and the needs of the application; Spring’s documentation provides the mechanisms, not a universal point at which every team should switch from derivation to a declared query. Use an explicit query, specifications, Querydsl, or a custom implementation when the expression becomes hard to read, needs explicit joins, or depends on database-specific behavior.
Choose pagination and sorting for the result you need
Repository methods can work with Pageable, Sort, and Limit. Spring Data JPA supports result abstractions including Page, Slice, and Window. Which one fits depends on whether the caller needs totals, how costly a count query is, how it navigates results, and whether it needs stable ordering. A result type alone does not guarantee lower latency or good deep-page performance.
| Result shape | What it provides | Decision to make |
|---|---|---|
Page<T> |
Total-element and total-page information. | Use when the interface genuinely needs those totals; consider the cost of obtaining a count for the query. |
Slice<T> |
A slice of results without requiring a full count in the same way as a Page. |
Useful when the caller needs to move through results but does not need totals; assess the query and navigation needs. |
Window<T> |
A window-style result abstraction supported for repository queries. | Consider it for large result sets where a scrolling or window-style API fits better than deep page navigation. |
For example, pass a Pageable argument to request a page and its sort order:
Page<Customer> findByLastname(String lastname, Pageable pageable);Use a stable ordering for navigable results so records have a predictable sequence. Check the generated SQL, indexes, and count-query cost against the actual database and workload rather than assuming that Page, Slice, or Window is always the fastest option. The query-method reference documents these supported query method parameters and result abstractions.
Rank #4
Put transactions around the work that must succeed together
Declared query methods do not receive transaction configuration automatically. Repository methods can be redeclared with @Transactional; read operations are commonly configured with readOnly = true. For a use case that calls several repositories, make the service-layer transaction boundary visible so the related work runs within the intended transaction.
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
@Service
public class CustomerService {
private final CustomerRepository customers;
public CustomerService(CustomerRepository customers) {
this.customers = customers;
}
@Transactional(readOnly = true)
public List<Customer> findByLastname(String lastname) {
return customers.findByLastname(lastname);
}
}A modifying query needs write-capable transaction configuration and, where applicable, @Modifying on the repository query method. Treat readOnly as a transaction hint and configuration choice, not as a promise that every database will reject writes. See the Spring Data JPA transactionality reference for the documented transaction behavior.
Use other persistence features deliberately
Spring Data JPA also documents auditing, locking, projections, specifications, stored procedures, Querydsl predicates, custom repository implementations, and publishing events from aggregate roots. Each addresses a different design need:
- Auditing: record who changed data or when changes occurred.
- Locking: express a concurrency-control choice when updates may conflict.
- Projections: shape reads around the fields a particular consumer needs instead of always exposing a full entity.
- Specifications and Querydsl: build or compose filters when queries depend on runtime criteria.
- Custom implementations and stored procedures: isolate data-access behavior that does not fit a simple derived or declared query.
- Aggregate events: publish events from aggregate roots when the application’s domain design calls for them.
These facilities do not guarantee correct domain behavior by themselves. Test their effects, inspect generated SQL where relevant, and monitor the persistence behavior in the target database. The reference documentation and project page describe the available feature set.
Check release compatibility before starting a project
The Spring Data JPA project page displays version 4.1.1, but release and compatibility information changes over time. Verify the target Spring Boot and Java versions against the current project documentation before selecting dependencies or upgrading an existing application.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
