Almost every Spring WebFlux example out there is leveraging Spring Data MongoDB to build Reactive end to end solutions.
As I understand it, JDBC is inherently a blocking API and we'll not be getting reactive support for relational databases any time soon. Leveraging Spring JPA async queries and dedicated thread pools can potentially improve things but it is not a replacement for real Reactive support.
My question is. Ate there known limitations when using Spring WebFlux with a "blocking" persistence layer such as a Spring Data JPA? Would it even make sense to build a Reactive REST API on top of a traditional blocking persistence layer (in terms os scalability)?
It's true that currently we don't have JDBC drivers that provide reactive access to the databases. There are no limitations with using Spring WebFlux with a blocking data acess layer, at the same time, there are no tangible advantages either.
If you want all the benefits of reactive, async / non-blocking, you'll need to make the whole stack async / non-blocking. JDBC is indeed inherently a blocking API, so you can't build a fully reactive / non-blocking app if you need to access the database through JDBC.
Oracle seems to be working on a new, async / non-blocking database API, which is (provisionally) called ADBA, but there's not a lot of information on it available yet. It will probably take a few years before it's available. Besides the API itself, database vendors will also need to implement non-blocking drivers.