I get why you’re asking this. When you’ve been fighting with R2DBC’s concurrency quirks, missing cascade behavior, and the “request queue limit exceeded” error, it’s very tempting to throw your hands up and say:

“JPA just works — why does R2DBC feel so painful?”

But the truth is more nuanced. R2DBC isn’t “bad,” it’s just a very different tool with very different trade‑offs, and it’s easy to hit its sharp edges if you expect it to behave like JPA.

Let me break it down in a way that’s honest, practical, and grounded in real-world experience.

🧠 Why R2DBC feels harder than JPA

1. R2DBC gives you zero ORM features

No:

• cascade delete
• lazy loading
• entity graphs
• dirty checking
• automatic joins
• session cache
• flush modes

JPA hides a ton of complexity behind the scenes. R2DBC exposes all of it.

If you expect JPA behavior, R2DBC will feel like it’s “missing features,” but really it’s just not an ORM.

2. Reactive pipelines amplify concurrency

With JPA, everything is blocking and sequential.
With R2DBC, everything is async and parallel unless you explicitly control it.

That means:

.flatMap(...)

can easily create hundreds of concurrent DB calls, which JPA would never allow.

R2DBC gives you power, but it also gives you rope to hang yourself.

3. The Postgres R2DBC driver has strict backpressure limits

The error you hit:

Cannot exchange messages because the request queue limit is exceeded

is the driver telling you:

“You’re sending more concurrent queries than I can handle.”

JPA never has this problem because it serializes everything.

4. R2DBC requires you to think in terms of streams, not transactions

JPA:

• Opens a transaction
• Does a bunch of work
• Commits

R2DBC:

• Streams data
• Requires explicit transactional boundaries
• Doesn’t batch automatically
• Doesn’t buffer automatically

It’s a different mental model.

🧠 Why R2DBC is not “worse” — just different

1. R2DBC shines when you need high concurrency

If you’re building:

• streaming APIs
• event-driven systems
• high-throughput microservices
• WebFlux endpoints

R2DBC can outperform JDBC because it doesn’t block threads.

2. R2DBC gives you full control

You decide:

• how many queries run in parallel
• how to batch
• how to join data
• how to handle backpressure

It’s more work, but also more power.

3. R2DBC avoids thread starvation

Under heavy load, JPA can choke because it blocks threads.
R2DBC keeps the event loop free.

🧠 When R2DBC is the wrong tool

If your app:

• is CRUD-heavy
• uses complex joins
• relies on cascade operations
• needs lazy loading
• uses entity graphs
• is not reactive end-to-end

Then yes — JPA is a better fit.

R2DBC is not a drop-in replacement for JPA.
It’s a different paradigm.

⭐ My honest take

R2DBC doesn’t “suck.”
But it demands discipline:

• control concurrency
• avoid N+1 queries
• design your schema for reactive access
• use database-level cascades
• tune your connection pool
• avoid delete-and-reinsert patterns

If you treat R2DBC like JPA, it will absolutely punish you.

If you treat it like a reactive, low-level database client, it becomes a powerful tool.

If you want, I can help you evaluate whether your project is actually a good fit for R2DBC, or whether switching back to JPA would save you a lot of pain.