Spring Data JDBC vs JPA vs Raw JDBC

Direct Answer

Spring Data JDBC is an aggregate-oriented mapping and repository framework without JPA's persistence context, lazy loading, dirty checking, or general bidirectional relationship model. It generates SQL for repository operations and can run declared/custom queries. Direct JDBC or JdbcTemplate keeps SQL and row mapping explicit. JPA manages entity state and richer associations.

Code Example

// Java 17 + Spring Data JDBC: repository like JPA, but predictable
import org.springframework.data.annotation.Id;
import org.springframework.data.repository.ListCrudRepository;

class Order {                 // plain class, Spring Data JDBC annotations
    @Id private Long id;
    private String status;
    // getters / setters
}

interface OrderRepository extends ListCrudRepository<Order, Long> { }

// Usage:
Order order = orderRepository.findById(1L).orElseThrow(); // one SELECT, eager
order.setStatus("SHIPPED");
// Nothing persists yet — there is NO dirty checking:
orderRepository.save(order); // you must call save() to fire the UPDATE

Unlike JPA, modifying the entity does nothing until you explicitly call save() — no hidden flush.

Common Mistakes & Pitfalls

• Confusing it with JdbcTemplate: Freshers think Spring Data JDBC is just a renamed version of JdbcTemplate, when they're completely different tools. JdbcTemplate requires you to write SQL and map results; Spring Data JDBC generates SQL from repository methods and entity annotations.
• Expecting JPA features: Beginners use Spring Data JDBC expecting lazy loading or automatic dirty checking, then are surprised when every load is eager and every save requires explicit calls. They don't realize it's intentionally simpler than JPA.
• Assuming it's always lighter weight: Some freshers think Spring Data JDBC is automatically faster than JPA, but its eager loading can fetch more data than necessary. For read-heavy apps with complex graphs, JPA's lazy loading and caching might actually perform better.