I’ve been adding Quarkus support to StatLite, so I used it as an excuse to run equivalent Spring Boot and Quarkus apps side by side on a very small VPS.

Both ran the same workload with:

• JDK 25.0.4
• -Xmx80m
• H2
• the same JVM tuning
• one 512 MiB VM with 256 MiB swap
• one StatLite process monitoring both

The result was less straightforward than I expected.

Quarkus actually started with higher RSS: about 145 MiB vs 112 MiB for Spring Boot in one of the controlled observations.

After an hour under memory pressure, the relationship reversed: Quarkus was around 83 MiB RSS with ~33 MB heap used, while Spring was around 154 MiB RSS with ~50 MB heap used.

But RSS was hiding an important part of the story. Quarkus had about 91 MiB swapped out versus ~66 MiB for Spring, so Linux paging was doing a lot of work.

And 512 MB turned out to be too tight for running both reliably. In a later one-hour observation, after the earlier package-maintenance pressure had cleared, the machine exhausted its memory/swap margin and the kernel OOM-killed Spring.

So I wouldn’t read this as a clean “Quarkus uses X MB less than Spring” benchmark. My main takeaway was how quickly RSS stops being a useful framework comparison once the machine is under serious memory pressure.

Full write-up, measurements, JVM flags, and experiment record:

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

The article benchmarks Jactl script execution with differing number of blocking operations comparing throughput with Jactl built-in suspend/resume on Vert.x Event-Loops and throughput with Jactl on Virtual Threads. The benchmarks are run on both Java 21 and Java 25 with some surprising (to me at least) results.