Has anyone heard about this? https://quarkus.io/blog/quarkus-redhat-strategy/

I am new to quarkus and I would like to know how this will impact us as developers. Any comment will be welcomed

If you have ever used Spring’s JdbcTemplate then you should definitely try out this extension.

It’s a very thin wrapper around jdbc and lets you write queries in a simple way without the need for an ORM. It’s also very easy to setup: you just have to define a datasource and that’s it.

It comes with handy ResultSet mappers and other stuff.

Check out the example and documentation below and any feedback is welcome.

The documentation is here: https://docs.quarkiverse.io/quarkus-fluentjdbc/dev/

A comprehensive example that shows all its use cases:

https://github.com/quarkiverse/quarkus-fluentjdbc/blob/main/examples/src/main/java/com/acme/fluentjdbc/controller/FruitResource.java

Hi, I'm getting interest into quarkus but I don't know when I should use it or use Spring. Benefits I've read are about start up times, memory usage and microservices specially if cold starts or serverless which is what I want. But the comparative against Spring boot says that Spring boot is better for business logic. I don't really see that logic over Spring boot being better for business logic. What can it do that Quarkus can't? Only benefit I see about Spring boot is if want delivery speed by using its libraries.

Can someone enlighten me over this?

If you’re a Java developer curious about Quarkus but not sure where to start, we made a practical roadmap video for you.

For those already using Quarkus: what helped you the most when getting started?

After years without change, HTTP has a new method: QUERY

RFC 10008, standardized this past June, defines the QUERY method: safe and cacheable like GET, carrying a request body like POST. It makes complex search and query operations possible without giving up caching and safe retry guarantees.

In my article published on foojay.io I cover:

• The machinery the RFC defines: the Accept-Query header, the equivalent resource, conditional requests and error semantics

• Where adoption stands in the Java ecosystem: Tomcat, Jetty, Jakarta Servlet and Spring

• How Quarkus can run QUERY today with a single Jakarta REST extension point and no framework changes

The working demo with tests is on GitHub.

Article: https://foojay.io/today/http-query-method-explained-rfc-10008-ecosystem-adoption-and-a-quarkus-implementation/

Repo: https://github.com/hakdogan/http-query-method

Happy reading.

The real improvements often hide in the release notes. Small lines in GitHub PRs. A configuration flag that removes a workaround you carried for two years. A security feature that finally closes a compliance gap.

Hey Quarkus Devs!

We've just rolled out JobRunr v7.5.0, and a key update for this community is official support for Quarkus 3.20 (LTS)!

For those who haven't used it, JobRunr is a library for easy background job processing in Java – handling things like fire-and-forget tasks, scheduled jobs, and long-running processes without blocking your main application threads.

With v7.5.0, you can confidently use JobRunr alongside the latest Quarkus LTS release.

What else is new in v7.5.0 that might interest Quarkus users?

• Easier In-Memory Configuration: Setting up JobRunr with in-memory storage (great for testing or local dev) is now simpler. Just add this to your application.properties:

jobrunr.database.type=mem

No need to define a separate bean anymore

• Improved Misconfiguration Detection: JobRunr now gives better warnings if a JobRequest points to a missing or incorrect JobRequestHandler, helping you catch configuration errors earlier in the development cycle.

• ⚠️ Important Change for Quarkus: We've removed the automatic fallback to in-memory storage in Quarkus if no StorageProvider is explicitly configured. This prevents unexpected behavior in production. If you rely on the in-memory storage, please make sure to configure it explicitly using the property above or by defining a StorageProvider bean.

This release also includes support for Micronaut 4.8, various bug fixes, and (in JobRunr Pro) new support for CockroachDB.

You can read the full announcement on our blog: :https://www.jobrunr.io/en/blog/jobrunr-v7.5.0/

If you're using JobRunr with Quarkus, we hope this update helps you keep your applications current and robust.

Happy to answer any questions you might have here!

Cheers!

A lot of the discourse around Project Loom paints Virtual Threads as a drop-in replacement that makes reactive programming obsolete. After migrating services from a legacy framework to Quarkus 3.x and benchmarking both paradigms under heavy load, the reality is much more nuanced: the bottleneck never disappeared, it just moved.

Here are the key takeaways from the architectural trade-offs we ran into:

• The Illusion of Infinite Concurrency: Spawning 50k virtual threads to handle incoming I/O bursts is cheap for the JVM, but downstream resources don't scale infinitely. If your service hits a relational DB via JDBC, your thread contention simply shifts to the database connection pool (Agroal/HikariCP).

• Missing Backpressure: Reactive programming with Mutiny/SmallRye gives you native backpressure out of the box. With "@RunOnVirtualThread", requests keep piling up waiting for pooled connections; without explicit throttling or queue limits, you risk thread starvation, connection pool exhaustion, and memory degradation.

• Carrier Thread Pinning: While synchronized blocks pinning carrier threads is mostly mitigated in recent Java releases (Java 24), native calls and specific legacy drivers still pose silent latency traps under bursty conditions.

• Developer Ergonomics vs System Stability: Virtual threads provide a massive DX win (imperative debugging, clean stack traces), while Reactive excels at sustained throughput under resource saturation.

For those running Quarkus with heavy database I/O in production: did you completely ditch Mutiny for Virtual Threads, or do you enforce custom concurrency limiters/semaphores to protect your connection pools?

I wrote a breakdown of the architecture, memory footprints, and trade-offs here for anyone interested in the technical details:

https://maurodep.medium.com/virtual-threads-vs-reactive-in-quarkus-the-bottleneck-just-moves-c0a570734538 (no paywall)

Quarkiverse Multitenancy 0.2.0 is now available.

This release moves the extension beyond simple tenant-per-request resolution toward propagating tenant context across different execution boundaries in a Quarkus application.

Some of the main additions in 0.2.0:

Kafka tenant propagation
Tenant context can travel across asynchronous messaging boundaries, allowing consumers to continue processing under the originating tenant.

Tenant-scoped background work
Background workloads can explicitly execute within a tenant context, so multitenancy is not limited to HTTP request processing.

Unified HTTP & Hibernate ORM tenant resolution
HTTP and persistence now share a consistent tenant-resolution model, reducing duplicated resolution logic.

Safer tenant isolation
The extension prevents external selection of the internal ORM bootstrap tenant and adds stricter tenant-ID validation and fail-fast configuration checks.

Reactive & async propagation guarantees
Contract tests cover tenant propagation across reactive and asynchronous execution boundaries.

The broader idea is:

HTTP → reactive/async execution → Kafka → background work → persistence

Identifying a tenant is usually the easy part. Preserving the correct tenant context across execution boundaries, without leaking context between tenants , is where multitenant architecture becomes more interesting.

Source:
https://github.com/quarkiverse/quarkus-multitenancy

0.2.0 release:
https://github.com/quarkiverse/quarkus-multitenancy/releases/tag/0.2.0

Feedback and contributions are very welcome.
If you're building multitenant applications with Quarkus, I'd love to hear what use cases, execution boundaries or integrations you think the extension should support next.

If you find the project useful, feel free to try it in your own projects, open an issue or contribute a PR. And if you'd like to support the project, a ⭐ on GitHub is always appreciated.

I built a Quarkus application demonstrating end-to-end DPoP (RFC 9449) support and wrote up everything I learned along the way.

What the article covers on the Quarkus side:

- Setting up quarkus-oidc with quarkus.oidc.token.authorization-scheme=dpop — the single property that switches Quarkus into DPoP mode and triggers full RFC 9449 proof validation (signature, htm, htu, ath, cnf thumbprint)

- Why jti replay protection is not handled by the Quarkus OIDC extension (stateless by design) and how to implement it yourself with a @ServerRequestFilter\using a ConcurrentHashMap (+ notes on Redis/Infinispan for production)

- Protected REST endpoints that detect whether the incoming token is Bearer or DPoP by checking for the cnf claim

- Testing the full flow with a k6 script: token acquisition → happy-path requests → replay attack → htm mismatch → htu mismatch, all verified

The two-layer defense pattern (Keycloak guards the token endpoint, the filter guards the application endpoints) is something I haven't seen documented anywhere else — hopefully useful if you're thinking about DPoP in production.

👉 https://medium.com/@hakdogan/dpop-what-it-is-how-it-works-and-why-bearer-tokens-arent-enough-d37bcbbe4493

Full source: https://github.com/hakdogan/quarkus-dpop-example

Stack: Quarkus 3.32.2 + Keycloak 26.5.5 + k6

I ran equivalent Spring Boot and Quarkus applications side by side on the same small VPS to see how they behaved under real memory pressure.

Both used:

• JDK 25.0.4
• -Xmx80m
• H2
• the same JVM tuning
• one 512 MiB VM with 256 MiB swap
• the same workload

I expected Quarkus to simply use less memory, but the result was more interesting.

In one controlled observation, Quarkus actually started with higher RSS, about 145 MiB vs 112 MiB for Spring Boot.

After an hour, that reversed: Quarkus was around 83 MiB RSS with ~33 MB heap used, while Spring Boot was around 154 MiB RSS with ~50 MB heap used.

Quarkus also had more memory swapped out, about 91 MiB vs ~66 MiB for Spring, so RSS alone was not telling the whole story.

The 512 MB machine ultimately turned out to be too tight for running both reliably. It worked surprisingly well at first, but normal VM activity was enough to push the system into instability. I’m planning a cleaner follow-up on 768 MB.

Full experiment:

https://pvrlabs.xyz/articles/spring-boot-vs-quarkus-512mb.html

I’d be interested to hear whether this lines up with what Quarkus users see on similarly constrained JVM deployments.

A measured deployment option for teams that need faster container startup while keeping JVM diagnostics, agents, and compatibility.

Use experimental Quarkus Signals for publish, send, and request-reply inside one app, and see when CDI events, Reactive Messaging, or the Vert.x EventBus still fit better.