I ran equivalent Spring Boot 3.5 and Quarkus 3.39 applications side by side on the same 512 MB VPS.

Both were **JVM applications running on JDK 25**. Quarkus native image was not used.

Both had the same workload, H2 database, `-Xmx80m`, Serial GC, and the same JVM tuning.

A few results surprised me:

* Quarkus initially had the higher RSS
* after sustained memory pressure, Quarkus had the smaller JVM heap and resident set
* RSS alone was misleading because Linux was swapping the two processes differently
* 512 MiB RAM + 256 MiB swap ultimately did not provide enough headroom for both JVMs
* in a later observation, the kernel selected Spring Boot as the OOM victim

This was deliberately **not a throughput benchmark**. Traffic was very light. I was interested in what happens to two JVM applications when the entire machine is constrained enough that paging, process residency, and eventually the OOM killer become part of the picture.

One interesting monitoring detail was that Spring’s HTTP metrics included a lot of Actuator polling traffic, while Quarkus’ `/q/metrics` scrapes were not counted as regular application requests, so the request charts cannot be compared directly.

My main takeaway wasn’t “Quarkus uses less memory.” On a machine this small, RSS stops being a simple framework ranking because the OS is actively deciding what stays resident.

Full write-up with measurements, JVM flags, screenshots, and limitations:

[https://pvrlabs.xyz/articles/spring-boot-vs-quarkus-512mb.html](https://pvrlabs.xyz/articles/spring-boot-vs-quarkus-512mb.html)

Spring Boot vs Quarkus on a 512 MB VPS with JDK 25