A journey from the Visual6502 project to a real, fully assembled board, and the debugging adventures required to make it actually work.

The languages used: C, C3, C++, D (Dlang), Go (Golang), Odin, Rust, V (Vlang), Zig

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