R2DBC vs JDBC + VirtualThreads

[Dimitris Zarras (dzarras)]

Hi,

JEP-444 (Virtual Threads) is GA since Java 21, and JEP-491 (Synchronize Virtual Threads without Pinning) is GA since Java 24.
In the meantime JDBC drivers have been working to resolve Pinning issues and adapt to Virtual Threads.

Currently, the following is proposed in the documentation:

Choose JDBC when you need simplicity, broad database compatibility, or are building a traditional application with moderate concurrency requirements. Choose R2DBC when building reactive applications, working with Kotlin coroutines, or needing to handle many concurrent connections efficiently with limited resources.

I know that Virtual Threads are meant to help scale web applications that use the Thread-per-Request model, given that JDBC drivers have adapted to Virtual Threads though, does it make sense for someone to prefer exposed-jdbc using a Dispatcher based on Executors.newVirtualThreadPerTaskExecutor(), over exposed-r2dbc?

With the advent of Virtual Threads, is R2DBC still relevant?

Kind regards.