Is Micronaut Data with R2DBC a more scalable approach than classical “one thread per connection” model Micronaut Data JDBC

Question

According to micronaut-data reactive guide,

"... In the case of reactive execution and if the backing implementation is blocking, Micronaut Data will use the Configured I/O thread pool to schedule the query execution on a different thread.

If the backing implementation natively supports reactive types at the driver level then the I/O thread pool is not used and instead it is assumed the driver will handle the query in a non-blocking manner..."

My straight question: accessing a Relational Database (eg. PostGres R2DBC driver) throw R2DBC will Micronaut Data rely that R2DBC driver will handle in a non-blocking manner and be more scalable?

Supposing my microservice expose a Reactive endpoint based on ReactiveX and has to access a blocking data source throw Micronaut Data JDBC (eg. there isn't yet Oracle R2DBC in production version), it is clear from above that it "will use the configure I/O thread pool" while accessing data. Am I losing totally the benefits o Reactive endpoint?

It is my first project with Micronaut and I have few ones with Reactive approach. I am far to be an expert in Reactive best practices but I remenber have read in several blogs: avoid use reactive stack if you have blocking source. I also remember read that you can have worse result mixing non-blocking with blocking design mainly because the way Eventloop (eg. Netty) is designed. Since I will use Micronaut with ReactiveX and Relational Database, some cases with R2DBC and others with JDBC, I will gratefull any comment on my doubt.

Answer 1

You are not entirely losing the benefits since if you have HTTP requests that are not blocking you can compose those operations with your JDBC logic.

However if you want true non-blocking with R2DBC see https://github.com/micronaut-projects/micronaut-r2dbc/