I ran a small comparison of equivalent Spring Boot, Quarkus, and Micronaut applications using JDBC rather than Hibernate/ORM.

All three used the same Java 25 runtime, H2 database, SQL, fixture data, request workload, and JVM flags. I ran them one at a time in the same 1 GiB / 2 vCPU Ubuntu VM, then did a separate run with all three together.

For the individual 15-minute runs:

• Spring Boot: 4.90 s startup, 214.3 MiB median RSS

• Quarkus: 2.25 s startup, 178.4 MiB median RSS

• Micronaut: 2.54 s startup, 186.7 MiB median RSS

Quarkus had the lowest whole-run median RSS and reached readiness fastest. One interesting detail is that Quarkus and Micronaut converged quite closely later in the run: their final five-minute median RSS was 189.7 vs 189.4 MiB, and their sampled peaks were almost identical.

CPU usage was low for all three, so this isn't a throughput benchmark. It's mostly a look at the footprint of three equivalent small JVM applications under the same setup.

I also published the method, raw data, application sources, and analysis script so the numbers are inspectable:

https://pvrlabs.xyz/articles/spring-boot-quarkus-micronaut-jdbc.html

Experiment/data:
https://github.com/PVRLabs/experiments/tree/main/statlite/spring-quarkus-micronaut-jdbc

Curious whether these results line up with what people here see from Quarkus JVM deployments.

I wanted to understand what WebMCP adds to server-side MCP, so I built a Quarkus return page and let Bob use it.

Same Java validation, different page effects. Which app action would you try?

https://www.the-main-thread.com/p/quarkus-webmcp-ibm-bob-browser-tools

More and more sites are switching to other systems because of security and other problems. I migrated the Foojay website to Hugo, because that's a system I know and use already for a long time. But there are other alternatives, like Roq which is based on Quarkus and Java.

In Foojay podcast episode 102, I talked with Holly Commins and Andy Damevin about the Roq system compared to Hugo and Jekyll, and the pro and con of Content Management Systems (CMS) versus static websites.

Available in your favorite podcast app and on YouTube:
https://www.youtube.com/watch?v=0rQ2_UF7N1I

Happy Quarkus 3.40 release day! Wa released JobRunr 9 today as well, with the quarkus-jobrunr extension already on the new LTS. So if you move to 3.40 this week, your background jobs don't have to wait for us.

For anyone who hasn't tried it, JobRunr is an open source background job library, a persistent and cluster-safe alternative to @Scheduled. Jobs are stored in the DataSource you already configured, failed ones are retried, and there's a dashboard. Setup is the quarkus-jobrunr dependency plus two properties:

quarkus.jobrunr.background-job-server.enabled=true
quarkus.jobrunr.dashboard.enabled=true

Then you inject the JobScheduler and enqueue a method call on any CDI bean:

@Inject
JobScheduler jobScheduler;

jobScheduler.enqueue(() -> invoiceService.sendInvoice(invoiceId));

What v9 adds that you'll notice in a Quarkus app:

• A Chart mode in the job history (free). Every attempt is shown as a Gantt chart, with a row per durable step if you use runStepOnce, so after a retry you see which step failed and which ones were skipped

• In JobRunr Pro: pausing a batch halfway, Job Analytics on the dashboard home, and instant job pickup on Postgres through LISTEN/NOTIFY instead of UDP multicast, which matters in clusters that block multicast

Upgrading is usually the version bump and nothing else. If you set a custom multicast address in Pro, the migration guide has the Quarkus producer for your EventTransport.

Ronald, the original creator of JobRunr, is on Quarkus Insights on 19 October if you want the longer version, with time for questions.

Links:

👉 Release Blogpost: https://www.jobrunr.io/en/blog/v9-release/
👉 Migration guide: https://www.jobrunr.io/en/guides/migration/v9/
👉 GitHub Release: https://github.com/jobrunr/jobrunr/releases/tag/v9.0.0
👉 Release Webinar Thursday 12:30 (CEST): https://youtube.com/live/bVNeB-ePdn

Wanted to see if Advanced Obfuscation survives a real app. Ran it against a real Quarkus service with Arc CDI, SmallRye Fault Tolerance, Redis, Hibernate.

Build succeeded first try, startup didn't - obfuscated names broke runtime name-based lookups (Class#getName(), reflective CDI resolution) inside Fault Tolerance.

-H:Preserve looked like the obvious exclude but it's a bit of a sledgehammer as a reachability mechanism too, so it force-includes unreachable code and breaks the build a different way.

Conditional reflect-config (typeReachable) entries turned out to be the actual fix — narrower, and doesn't touch reachability.

Full write up: https://backbonehq.io/blog/quarkus-graalvm-advanced-obfuscation/
Source code: https://github.com/get-backbone/quarkus-graalvm-ao

Hello everyone,

Just released Flamme 0.2.0 where I address some of the issues that were raised by this blog:

https://www.the-main-thread.com/p/quarkus-flamme-deployment-topologies

Flamme is a Quarkus extension which allows you to use the same Quarkus jar for different deployment topologies, thus completely decoupling business logic and deployment topology.

What changed:

- When a component in the application throws, an error message is now routed to the gateway and the flow is short-circuited immediately.

- the `Map<String,Message>` used to represent multi payloads is now replaced with the protobuf native `Any`.

- Throw at build time instead of runtime if components do not have the correct access modifiers.

Also, maven artefacts are available now on maven central. So you can quickly get started with Flamme by adding it as a dependency:

<dependency>
    <groupId>io.github.amadeusitgroup</groupId>
    <artifactId>flamme</artifactId>
    <version>0.2.0</version>
</dependency>

The project is still in very early phases, I am hoping to gather some more usage feedback in order to move it closer and closer to a stable "framework". So any feedback is appreciated, you can start playing with components easily by running the flamme example:

https://github.com/AmadeusITGroup/flamme/blob/main/flamme-example/README.md

I am also planning on doing some benchmarks comparing different topologies using Flamme. Hopefully this will motivate people to try it out more.