JpaRepository vs CrudRepository vs PagingAndSortingRepository

Direct Answer

Spring Data defines a hierarchy of repository interfaces — pick the one whose contract matches your need. Repository<T, ID> is the empty marker interface enabling Spring Data scanning. CrudRepository<T, ID> adds CRUD methods (save, findById, findAll, delete). PagingAndSortingRepository<T, ID> (since Spring Data 3 it is separate from CrudRepository) adds findAll(Pageable) and findAll(Sort). JpaRepository<T, ID> combines CRUD + paging + JPA-specific methods (flush(), saveAllAndFlush(), getReferenceById(), deleteAllInBatch()). For most JPA apps, extend JpaRepository. Extend CrudRepository (with separate PagingAndSortingRepository if needed) when you want a smaller surface area, persistence-tech portability, or do not need JPA-specific methods.

Code Example

Standard repository — extends JpaRepository:

public interface OrderRepository extends JpaRepository<Order, Long> {
    List<Order> findByStatus(OrderStatus status);
}

Narrow API — only what you want exposed:

public interface OrderLookup extends Repository<Order, Long> {
    Optional<Order> findById(Long id);
    Order save(Order order);
}

No deleteAll(), no findAll() — callers cannot misuse the repository.

Read-only paging repository:

public interface OrderReportRepository
        extends ListPagingAndSortingRepository<Order, Long> {
    Page<Order> findByCreatedAtBetween(Instant from, Instant to, Pageable page);
}

No writes possible.

Persistence-neutral domain repository:

public interface CustomerRepository extends ListCrudRepository<Customer, UUID> {
    Optional<Customer> findByEmail(String email);
}

Can later swap from JPA to MongoDB / R2DBC by changing only the implementation tech.

Common Mistakes & Pitfalls

Extending JpaRepository everywhere without realizing it exposes JPA-specific operations and ties the repository contract to JPA forever