Introduction

Spring Data projections are useful when you want a query result shaped for a specific read use case instead of returning the whole entity. The key question is not whether projections are available. The key question is what problem they solve in your case. If the caller still needs the full entity, a projection may add indirection without much benefit.

The Real Benefit of a Projection

A projection is most valuable when it gives you a smaller or more stable read contract. That usually means one of these:

• you only need a subset of fields
• you want to keep the caller from depending on the full entity
• you want a result shaped for a screen, API response, or report
• you want a read-only view rather than an object with entity behavior

If none of those applies, returning the entity may be simpler and clearer.

Closed Interface Projections Fit the Common Case

An interface projection works well when its getters map directly to actual entity properties. That is often called a closed projection.

1public interface UserSummary {
2    Long getId();
3    String getUsername();
4    String getEmail();
5}
6
7public interface UserRepository extends JpaRepository<User, Long> {
8    List<UserSummary> findByActiveTrue();
9}

This is a good fit if the caller only needs those three values. The repository method communicates that the result is a read model, not the full User aggregate.

Projections Are Weak When They Mirror the Entity

If your projection exposes almost every field from the entity, the practical gain is often small.

1public interface AlmostUser {
2    Long getId();
3    String getUsername();
4    String getEmail();
5    String getPhone();
6    String getAddress();
7    boolean isActive();
8}

If the service layer immediately needs the full entity afterward, the projection did not really simplify anything. It only changed the return type.

That is often the answer to "what is the real reason in my case?" The real reason may be that there is no strong reason unless you are intentionally narrowing the data shape.

DTO Projections Are Better for Explicit Read Models

When the result is meant for a UI card, API payload, or report row, a DTO projection is often clearer than an interface because the returned shape is explicit Java code.

1public record UserCard(Long id, String username, String email) {}
2
3public interface UserRepository extends JpaRepository<User, Long> {
4    @Query("""
5        select new com.example.UserCard(u.id, u.username, u.email)
6        from User u
7        where u.active = true
8        """)
9    List<UserCard> findActiveUserCards();
10}

That is a deliberate read model. It says exactly what the query returns and avoids exposing unrelated entity fields.

Open Projections Are Convenient but Less Precise

Spring Data also supports open projections with computed values, often through @Value. They are convenient for light formatting, but they are not the cleanest default for every case.

1public interface UserLabel {
2    String getUsername();
3
4    @Value("#{target.username + ' <' + target.email + '>'}")
5    String getDisplayLabel();
6}

Open projections are handy, but if the logic becomes non-trivial, a DTO or service-layer mapper is usually clearer.

A Simple Decision Rule

Use a projection when it gives you a narrower, intentional read contract. Do not use one simply because Spring Data supports it.

A good checklist is:

1. Do I need fewer fields than the entity contains?
2. Do I want the result shaped for one specific caller?
3. Am I trying to avoid coupling higher layers to the entity model?

If the answer is mostly yes, use a projection. If the answer is mostly no, returning the entity is often the better choice.

Common Pitfalls

• Creating a projection that mirrors almost the entire entity.
• Assuming projections automatically produce a meaningful performance win.
• Using open projections for logic that belongs in a DTO or service layer.
• Returning a projection when the caller later needs full entity behavior anyway.
• Treating projections as an architectural rule instead of a tool for specific read cases.

Summary

• Spring Data projections are for shaping query results, not for abstraction by default.
• Closed interface projections are useful when you need a subset of entity fields.
• DTO projections are strong when you want an explicit read model for an API or UI.
• Open projections are convenient but should stay simple.
• If your projection is nearly the same as the entity, the real benefit is usually small.