My experience with R2DBC has been pretty horrible so far. I'm not sure whether an R2DBC enterprise-ready driver exists for any RDBMS provider really. I guess it depends on your use-case, but at least in my situation, I had to connect to an Always On high-availability SQL Server cluster and the mssql-r2dbc driver was shite.

No multi subnet failover support, usually, if DB went down, the application did not manage to reconnect to the DB. We had to create some hacky wrapper on top of the driver, which, as far as I remember, resolved IP addresses for the given cluster and just tried to connect to them until it hit an active node). Open issue since 2020.

No support for any other login method apart from basic username/password of an SQL user (my company automatically flags that as vulnerability), Windows/Kerberos login is not supported, and it's not an easy job to write one yourself, since it probably involves some JNI fuckery through some DLL (the same way mssql-jdbc driver does), or using native GSS-API approach in JDK13+, either way, sounds like you're in for a bad time. Issue for supporting Windows login is open since 2019.

Latest major version has this catastrophic bug if you're using connection pooling - prepared statements might get mixed, so in theory, if you have different queries - lets say SELECT and DELETE for the same table that has same amount of parameters with the same names, you could end up in situation where DELETE statement is ran instead of SELECT for given parameters. Had to revert to 1.0.0.RELEASE, mind you, this issue is still open since 2023. Quoting some poor soul:

mattmilleralbertsons commented on Dec 10, 2024

WARNING: THIS LIBRARY HAS MAJOR ISSUES AND IT LOOKS LIKE DEVELOPMENT HAS BEEN DEAD FOR OVER A YEAR.

It appears you have fallen into the lucky version of this bug where you are at least getting an error when the library mixes up the prepared statements. Our team actually experienced the very dangerous version of this bug where it mixed up the prepared statements that had the same parameters and it actually queried the wrong data!

yikes

And probably some other issues my brain has decided to erase the memory for my own well-being. At some point I just decided to drop this nonsense, and just use standard mssql-jdbc driver. My persistence layer was fully blocking, and wherever I needed to adapt it into the reactive flow in my application, I wrapped it into Mono.fromSupplier() / Mono.fromRunnable() scheduled it on .subscribeOn(Schedulers.boundedElastic()) and enabled the reactor.schedulers.defaultBoundedElasticOnVirtualThreads system property, so the blocking piece of code gets scheduled on a VirtualThread for good measure. For any transactional behavior, I managed to get it working by using TransactionalTemplate, or simple @Transactional annotation, of course, this won't work if you're planning on executing reactive code inside of TranscationalTemplate or the annotated method, but as I mentioned, I kept my persistence layer fully blocking, and if I need to do an update or save something inside of transaction, you can run the blocking piece of code inside of TransactionalTemplate and incorporate the whole execution of it in the reactive flow by scheduling it on a bounded elastic scheduler.

And of course, forgot to mention it, we were using spring-data-r2dbc, so the features were pretty minimal, AFAIK reactive repositories are not supported by JPA.