On Using Spring JDBC which works very well and has some improvements over JPA when using Batch processing.
I would love to learn why to use Spring Data JDBC when you already have Spring JDBC.
I would love to learn why to use R2DBC when you already have Spring JDBC.
The three technologies work on different abstraction levels.
R2DBC is an alternative to JDBC. It is reactive, i.e. non-blocking. You send a statement to the server, continue to work and eventually receive the results as an event. It is often used for the ability to better scale. But using it is more complex because it is asynchronous and basically your complete application should be too in order to get the benefits. As with JDBC you probably don't want to use it on its own.
Spring JDBC is comparable to Spring R2DBC both hide some of the more tedious details of the underlying technology. They both offer pretty much full access to the underlying technology and just give you a more pleasant developer experience.
Spring Data JDBC is an Object Relational Mapper (ORM) based on the Repository abstraction. For the reactive world there is also Spring Data R2DBC which shares code and properties with Spring Data JDBC. It is basically a replacement of Spring Data JPA. For a comparison of Spring Data JDBC and Spring Data JPA see https://stackoverflow.com/a/42488593/66686. The Repository abstraction of Spring Data comes from Domain Driven Design. You can think of a Repository as a collection that is backed by some persistence mechanism. The elements of that collections are not just entities but aggregates, which belong together and don't make sense on their own. A typical example is a Purchase Order with its Line Items. A Line Item doesn't make much sense without its Purchase Order.
This approach puts some constraints on the design of your domain model. In return you get a nice clean structure for you domain model. Both Spring Data JDBC and Spring Data R2DBC allow to combine them freely with Spring JDBC and Spring R2DBC. This is very different for JPA and everything build on it, because JPA has a cache as integral part of the system which will lead to interesting effects when you mix JPA and direct JDBC access within a single transaction.
See the following table for an overview of the different technologies discussed.
| Stack | JDBC to Spring Data JDBC | R2DBC to Spring Data R2DBC | JDBC to Spring Data JPA |
|---|---|---|---|
| Underlying API | JDBC | R2DBC | JDBC |
| Usability Layer | Spring JDBC | Spring R2DBC | Spring ORM (*) |
| ORM | Spring Data JDBC | Spring Data R2DBC | JPA |
| Repository Abstraction | Spring Data JDBC | Spring Data R2DBC | Spring Data JPA |
| Communication Style | synchronous | reactive | synchronous |
(*) Spring ORM sits on top of JPA or other Spring independent ORM technologies, so in this table it kinda should be below JPA.
When you would use R2DBC is easy, it’s when you are building an application that is non-blocking. Everything in the stack has to be non-blocking, including the database driver. JDBC is inherently blocking, people try schemes to get around it but it is not great. If you aren’t building a non-blocking application you wouldn’t use R2DBC.
For the part about when to use spring data JDBC, it looks like it gives you a simpler way to create repositories and map data, as long as you’re ok with their opinionated framework, you are ok with not having all the complex mappings you get with JPA, and you want the DDD concepts (like aggregate root). Otherwise Spring JDBC requires more code to create your data access objects but may give more control. https://docs.spring.io/spring-data/jdbc/docs/2.2.4/reference/html/#reference describes more about why to use Spring Data JDBC. It is simplicity vs control.