CrudRepository vs JpaRepository in Spring Data JPA

By the end of this page, you will understand how CrudRepository and JpaRepository are related, what methods each one provides, and when to choose the simpler interface versus the more feature-rich one in a Spring Data JPA application.

CrudRepository and JpaRepository are both repository interfaces from the Spring Data ecosystem, but they serve slightly different levels of functionality.

At a high level:

• CrudRepository gives you the basic Create, Read, Update, Delete operations.
• JpaRepository includes everything from CrudRepository and adds extra features that are useful specifically for JPA-based applications.

The inheritance relationship

JpaRepository is not completely separate. It builds on smaller repository interfaces.

The hierarchy is roughly:

Repository
  └── CrudRepository
        └── PagingAndSortingRepository
              └── JpaRepository

That means:

• If you use JpaRepository, you also get all methods from CrudRepository
• JpaRepository is a more specialized interface for JPA
• CrudRepository is the minimal common choice when you only need basic data access

What CrudRepository provides

Think of these interfaces like toolboxes:

• CrudRepository is a basic toolbox with the essential tools: save, find, delete, count.
• JpaRepository is a larger toolbox that includes the basic tools plus advanced ones for JPA-specific tasks.

If all you need is a screwdriver and a hammer, the small toolbox is enough. If you also need a wrench set, measuring tape, and specialized tools, the larger toolbox saves time.

Both can do the basic job. The difference is how many built-in tools you want available.

A repository interface in Spring Data JPA is usually declared by extending one of the Spring Data repository interfaces.

Using CrudRepository

import org.springframework.data.repository.CrudRepository;

public interface UserRepository extends CrudRepository<User, Long> {
}

This gives you basic methods like:

userRepository.save(user);
userRepository.findById(1L);
userRepository.findAll();
userRepository.deleteById(1L);

Using JpaRepository

import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Long> {
}

This gives you all CRUD methods plus JPA-specific ones like:

userRepository.saveAndFlush(user);
userRepository.findAll();      // returns List<User>
userRepository.flush();
userRepository.deleteAllInBatch();

Example entity

Consider this repository:

public interface UserRepository extends JpaRepository<User, Long> {
}

And this service code:

User user = new User(1L, "Ava");
userRepository.save(user);
List<User> users = userRepository.findAll();
userRepository.flush();

What happens step by step

1. new User(1L, "Ava")

   • A new Java object is created in memory.

2. userRepository.save(user)

   • Spring Data delegates the save operation to the JPA provider.
   • If the entity is new, it will be inserted.
   • If it already exists, it may be updated.

3. userRepository.findAll()

   • A query is executed to fetch all User rows.
   • Because this is JpaRepository, the result is returned as a List<User>.

Here are common situations where these interfaces appear in real applications.

When CrudRepository is enough

• A small internal app with simple create, read, update, delete screens
• A microservice that only stores and fetches records by ID
• A codebase where the team wants to expose only minimal repository operations
• Teaching or learning examples focused only on basic persistence

When JpaRepository is more useful

• Applications that need pagination and sorting often
• Services that work with JPA-specific behavior like flushing or batch deletes
• Admin dashboards that list many records and need List results directly
• Larger enterprise apps where repository convenience methods save development time

Example scenarios

• User management system: JpaRepository is convenient because you may need paging, sorting, and bulk operations.
• Simple key-value style entity storage: CrudRepository may be enough.
• Order processing app: JpaRepository can help when flushing changes before later transaction logic depends on them.

In real projects, developers often choose a repository interface based on how much behavior they want available by default.

Common pattern: use JpaRepository as the default

Many Spring Boot applications use:

public interface OrderRepository extends JpaRepository<Order, Long> {
}

Why?

• It is convenient
• It returns List for common methods
• It supports pagination and sorting through inherited interfaces
• It exposes JPA-specific helper methods

Common pattern: use a smaller interface intentionally

Some teams prefer:

public interface ProductRepository extends CrudRepository<Product, Long> {
}

This can help:

• keep APIs smaller
• reduce accidental misuse of advanced methods
• make the repository contract more focused

Validation and service-layer usage

Repositories are usually called from a service layer:

@Service
   {
      UserRepository userRepository;

      {
        .userRepository = userRepository;
    }

     User  {
         (user.getName() ==  || user.getName().isBlank()) {
              ();
        }
         userRepository.save(user);
    }
}

1. Thinking they are unrelated interfaces

A common misunderstanding is assuming you must choose between two completely separate repository systems.

In reality, JpaRepository extends the simpler repository interfaces.

2. Expecting CrudRepository.findAll() to return a List

Broken assumption:

CrudRepository<User, Long> repo = null;
List<User> users = repo.findAll(); // compile-time problem

Why it fails:

• CrudRepository.findAll() returns Iterable<User>
• JpaRepository.findAll() returns List<User>

Correct approach:

Iterable<User> users = repo.findAll();

Or use JpaRepository if a List is what you want.

3. Using JpaRepository methods when the repository only extends CrudRepository

Repository interface comparison

Quick reference

CrudRepository

public interface UserRepository extends CrudRepository<User, Long> {
}

Common methods:

save(entity)
findById(id)
findAll()
deleteById(id)
count()
existsById(id)

Notes:

• Minimal API
• findAll() returns Iterable<T>
• No flush() or batch JPA helpers

JpaRepository

public interface UserRepository extends JpaRepository<User, Long> {
}

Includes everything from CrudRepository plus:

findAll()            // returns List<T>
flush()
saveAndFlush(entity)
deleteAllInBatch()
deleteAllByIdInBatch(ids)
getReferenceById(id)

Notes:

What is the main difference between CrudRepository and JpaRepository?

CrudRepository provides basic CRUD operations. JpaRepository includes those operations and adds JPA-specific features such as flush(), saveAndFlush(), batch deletes, and List-based find methods.

Is JpaRepository a subtype of CrudRepository?

Yes. JpaRepository extends other Spring Data repository interfaces, including CrudRepository, so it includes all CRUD methods.

Should I always use JpaRepository in Spring Boot?

Not always, but many projects do because it is convenient. If you only need simple CRUD and want a smaller API, CrudRepository is still a good choice.

Why does findAll() return different types?

With CrudRepository, findAll() returns Iterable<T>. With , it returns , which is often easier to use in application code.

• Repository pattern - Both interfaces are examples of the repository abstraction for data access.
• Spring Data JPA - This is the framework that provides these repository interfaces and query generation.
• PagingAndSortingRepository - It sits between CrudRepository and JpaRepository and adds pagination and sorting.
• JPA persistence context - Important for understanding methods like flush() and entity state management.
• EntityManager - JpaRepository methods are closely related to JPA operations normally performed through the EntityManager.
• Derived query methods - Both repository types support method-name-based query generation.
• Optional in Java - Frequently used with findById() when retrieving entities safely.