Practice: Choosing Between Spring Data JDBC and JPA

One table, simple CRUD and a need for predictable SQL: which persistence model fits?

Spring Data JDBC suits flat domains that need predictable SQL, and Spring Data JPA suits domains with deep relationships that benefit from JPA loading related objects on demand and saving changed entities automatically. Apply that rule to the service below, and name the requirement that decides it.

A new service owns one table, notifications, with no relationships to any other table it manages. Reads and writes are simple CRUD, and the team wants SQL behaviour that is easy to predict under load. Spring Data JDBC or Spring Data JPA? And would the answer change if each notification also kept a list of its delivery attempts?

See the answer

Spring Data JDBC. There is no relationship depth for a persistence context (JPA's record of the entities it is tracking in the current transaction) to manage and no lazy loading (fetching related rows only when the code first reads them) worth having, and predictable SQL is an explicit requirement. The deciding requirement is the last one: JPA's deferred writes and lazy queries are exactly what makes SQL harder to predict.

The delivery attempts do not change it. They belong to one notification, so they are part of its aggregate, the group of objects saved and loaded as one, and are saved and loaded with it, which Spring Data JDBC handles directly.

← → move through sections and cards