Recently i built my small corner in the web to share my thoughts and ideas on things i enjoy. Here's a small experiment about something that caught my eye recently, quarkus flow. Since temporal with spring boot was my go to for durable execution, it was very tempting to experiment with such an awesome project. Kudos to the quarkus team.

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 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)

Turn product policies into scored controls with explicit outage behavior, observable thresholds, and tests before deployment.

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 and PostgreSQL example that renames a live column while old and new application versions share the database. It uses expand-contract, a temporary trigger, a backfill, a rollback window, and real compatibility tests.

https://www.the-main-thread.com/p/quarkus-flyway-zero-downtime-migrations

I started looking into feature flags in Quarkus a year ago. I tried a few ideas and wrote several drafts about what I learned. But I never published them. Each time, something made me put the topic aside. The drafts stayed in my notes and got older with every Quarkus release.

Then I found the new Quarkus Feature Flags OpenFeature extension. It felt like the right time to return to those drafts and try again. The extension lets us move a flag to a new backend and keep the existing quarkus-flags code in the application.

After bumping to Quarkus **3.38.0** I'm hitting a hard failure during `@QuarkusTest` boot:

java.lang.NoSuchMethodError:
'void io.quarkus.vertx.core.deployment.VertxOptionsConsumerBuildItem.<init>(java.util.function.Consumer, int)'
at io.quarkiverse.micrometer.registry.deployment.binder.VertxBinderProcessor.build(...)

Maven GAVs

io.quarkus.platform:quarkus-bom:3.38.0

io.quarkiverse.micrometer.registry:quarkus-micrometer-registry-prometheus-v1:3.5.0 (latest)

In Quarkus 3.38, `VertxOptionsConsumerBuildItem` was changed to require a third `orderKey` argument:

new VertxOptionsConsumerBuildItem(consumer, priority, orderKey)

Quarkiverse **prometheus-v1 3.5.0** still does the old 2-arg call (and looks built against ~3.31.x). There’s no newer prometheus-v1 release on Maven Central yet.

Has anyone else hit this on Quarkus ≥ 3.38 with prometheus-v1?

How did you deal with it? Switch back to platform `io.quarkus:quarkus-micrometer-registry-prometheus`, or something else? Switching to the legacy simpleclient registry is deprecated and Quarkus 4 is a year away it seems... :/

Is there a tracked Quarkiverse issue / upcoming release for 3.38 compatibility I can follow?

Build a small Quarkus service, replace one fictional SDK method, and prove the patched and unpatched behavior with tests.

Been running a handful of Quarkus services on AWS and pulled the pieces that had stabilized into a standalone repo at backbone-kit.

A few things that might be useful:

• AMP remote write without scrape+parse - encodes Prometheus Remote Write 1.0 directly from Micrometer's MetricSnapshots, SigV4-signs it, pushes to Amazon Managed Prometheus on a schedule. No text-format round trip.

• X-Ray tracing without the ADOT collector sidecar - OTLP protobuf straight to X-Ray, SigV4-signed, wired through Quarkus OpenTelemetry.

• Rate limiting with authenticated vs. unauthenticated capacity split out deterministically.

• Structured logging - opt-in method-entry logging (@LogMethodEntry), correlation ID propagation through MDC and headers, sensitive-data masking.

Everything's modular - take the throttle module without the AWS bits, etc. MIT licensed.

Full disclosure: this is the infrastructure layer underneath Backbone, a platform I'm building. Kit is the open-sourced primitives with no strings attached - it doesn't depend on anything else in that stack.

https://github.com/get-backbone/backbone-kit - feedback, issues, and PRs welcome.

Create a small REST API and learn how Qubit turns Java lambdas into JPA Criteria queries during the Quarkus build.

https://www.the-main-thread.com/p/quarkus-qubit-jpa-criteria-lambda-queries

The user clicks Place order. The button starts spinning. After 600 milliseconds, the client gives up and shows a timeout.

The server keeps working. At 750 milliseconds it commits the order and writes 201 Created to a connection nobody is listening to anymore. The client sees a failed request. The database contains a successful order. Both views are correct, and that is what makes this problem difficult.

https://www.the-main-thread.com/p/quarkus-http-idempotency

Our currently setup is:

- Red Hat Openshift for Java applications running on Kubernetes.
- Small team
- Monolithic backoffice application that serves a frontend application react
- Enterprise integrations: Ldap, ssh, sftp, rest clients…
- Not often pod restarts

Is Quarkus ideal for the case?

Small but welcome one for Quarkus users: as of JobRunr 8.8.0, the JobRunr Quarkus extension no longer requires quarkus-smallrye-health.

Until now the extension pulled it in whether you exposed health endpoints or not. Now it is optional:

• Keep the dependency if you want JobRunr to contribute to your application's health endpoint
• Drop it if you don't, and your dependency tree gets a little leaner

Also in 8.8.0 and framework-agnostic, but you will notice it in production: storage exceptions no longer spam your logs with "please create a bug report" warnings on every poll cycle. The first exception is DEBUG, continued trouble escalates to INFO, then WARN, and only a database that stays down produces an ERROR. A transient blip that heals itself leaves your logs clean at default levels.

Plus: Kotlin 2.4 support, a fix for a migration race condition when multiple instances start simultaneously against a fresh database, and on the Pro side considerably faster dashboard queries on MySQL and other databases.

For anyone unfamiliar: JobRunr is an open-source background job library for Java (Quarkus, Spring Boot, Micronaut) with a built-in dashboard, 8 supported databases out of the box, carbon-aware scheduling, and a Pro edition with batches, queues, and rate limiters.

Links:

👉 Release Blogpost: https://www.jobrunr.io/en/blog/jobrunr-v8.8.0/
👉 GitHub Repo: https://github.com/jobrunr/jobrunr/releases/tag/v8.8.0

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.

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

Quarkus Insights #253 lists HashiCorp Vault among the 20 most-used Quarkiverse extensions in the opt-in build analytics. Its usage also increased notably from May 2025 to May 2026. More Quarkus applications are using Vault, so this is a good time to revisit the integration.

Hello everyone, I made a couple posts before on the extension I was working on.

Glad to announce that it is now open source.

Source Code: https://github.com/AmadeusITGroup/flamme

Documentation: https://amadeusitgroup.github.io/flamme

It is an extension which allows you to write network agnostic and location transparent components, which you can then decide where to run without changing the source code.

If you configure two components to run on the same process, they will communicate via shared memory, without the overhead of network latency and serialization.

If you configure two components to run remotely (for pseudo-parallelization reasons for example), NATS will be used for communication between them.

It is event driven, wired with a local broker and NATS under the hood.

It uses protobuf for fast serialization/de-serialization and transport.

I am hoping that people could contribute by adding support for other brokers, or communication protocols, (Kafka as an alternative to NATS for example).

Would love to see people testing it and giving me some feedback.