Difference between using JDBC and R2DBC connection for Jooq

The documentation for Reactive Fetching in Jooq mentions:

> Out of the box, all jOOQ provided publishers will block on the underlying JDBC connection, but if you provide jOOQ with a io.r2dbc.spi.Connection or io.r2dbc.spi.ConnectionFactory, then the publishers will execute queries in a non-blocking fashion on an R2DBC driver.

I am trying to understand what is the difference between using the io.r2dbc.spi.Connection and java.sql.Connection when we are already wrapping the publisher in fromPublisher methods available in the rx-java.

For example (the code is identical for both R2DBC and JDBC, only the context ctx is constructed differently):

Flowable.fromPublisher(ctx.select(...).where(...)).subscribe(...);

If this code is being run on Thread 1, it shouldn't immediately block that thread in either case (because it's a Flowable created from the publisher provided by jooq).

But then, in the JDBC case, will it later block the same Thread 1, or some other thread?

My current understanding, based on https://github.com/r2dbc/r2dbc-spi/issues/162#issuecomment-598908146 is that R2DBC reduces the number of threads required as compared to JDBC for an equivalent number of simultaneous DB connections.

Is this understanding correct and complete?

For more context, we're using Vertx + jooq + R2DBC and are trying to evaluate whether it's possible to write a scalable system using JDBC instead of R2DBC.

This isn't really jOOQ specific, although jOOQ helps you easily switch between JDBC and R2DBC drivers, without changing your client code. Logically, the switch should indeed not have too many effects, apart from the fact that there are always edge cases and bugs, especially in the R2DBC ecosystem, which isn't as mature as JDBC yet, and also jOOQ itself, given how hard it is to write correct reactive (or any concurrent) code.

The main value of R2DBC over JDBC, however, is that it allows for possibly reactive-capable wire protocols to push data to clients directly from within the database, whereas with JDBC, the client will always block somewhere.

Whether this actually has any tangible effects on your application is best measured by yourself in a real world scenario, after getting a feel of the reactive APIs themselves (which impose their own cognitive hurdles). Another benefit of jOOQ's design is that you can simply do this on a production (or integration test, benchmark, etc) workload, switching drivers, once you use jOOQ's Publisher API. I don't think there's anything proven or even fool proof in this area.

In the long run, scalability problems should be addressed by Loom in a more transparent way, for all implementations, including JDBC. My expectation here is that with the advent of Loom, the reactive programming model will go back to being mainly about the programming model (push instead of pull), rather than about scaling.