Spring Boot vs Quarkus on a 768 MiB VPS

Question

How do equivalent Spring Boot and Quarkus applications behave when they share the same 768 MiB host budget and deliberately bounded JVM settings?

Setup

The comparison ran on Ubuntu 24.04 x86_64 in a VM configured with 768 MiB of RAM, of which the guest exposed approximately 703.5 MiB, plus one vCPU and 256 MiB of swap. Both applications used Eclipse Temurin 25.0.4.1+1, Spring Boot 4.1.1, Quarkus 3.39.4, file-backed H2, and the same Star Pulse-style application shape.

Both JVMs used the same profile:

-Xms16m
-Xmx80m
-Xss256k
-XX:+UseSerialGC
-XX:TieredStopAtLevel=1
-XX:ReservedCodeCacheSize=32m
-XX:+UseCompactObjectHeaders

A loopback-only Python fixture supplied deterministic GitHub-like responses. StatLite 0.4.2 monitored Spring, Quarkus, itself, and the host. This follows the earlier Spring Boot vs Quarkus on a 512 MB VPS experiment, using the same startup order: Spring first, then Quarkus.

Run

After both applications were ready, I sent one deliberate request to each, started monitoring, and ran a paired workload ten times. Each repetition sent one request to Spring, one to Quarkus, and then waited one second. The controlled observation lasted ten minutes.

This is a memory-behavior observation, not a throughput benchmark or a framework-wide ranking.

Results

The RSS lines appear to converge over the ten-minute observation, but RSS alone is misleading here. Spring's RSS fell by about 26 MiB while its process swap increased by about 34 MiB. Part of the apparent convergence therefore reflects Linux paging Spring memory out of RAM, rather than Spring simply reducing its memory footprint.

Validity checks

• The paired workload completed with exactly ten HTTP 200 requests to each application.
• Spring, Quarkus, and StatLite stayed active with zero restarts.
• StatLite reported all monitored targets successfully with zero consecutive poll failures at closeout.
• No matching kernel OOM or service-failure signals appeared in the collected closeout journals.
• Final database files were 28 KiB for Spring H2, 32 KiB for Quarkus H2, and 172 KiB for StatLite SQLite.

What this suggests

For this application pair and this constrained VM, Quarkus used less resident memory and avoided process swap during the ten-minute run. Spring remained operational, but it had both a higher resident footprint and increasing process swap.

The conclusion is deliberately narrow. It does not establish that Quarkus is generally more memory-efficient or that it is a universal framework winner. The observation lasted ten minutes, and Linux paging is part of what was measured.

The same setup was repeated at 1 GiB with swap disabled. See the 1 GiB no-swap follow-up.

Dashboard views

These closeout screenshots show the monitored application and host dashboards. They provide operational context; the checkpoint table and chart above remain the primary measured evidence.

Spring Boot Quarkus Host resources

×

Evidence

The public experiment record contains the method, frozen inputs, workload contract, checkpoint data, polling summary, and selected screenshots.

Monitoring for this experiment was collected with StatLite, a lightweight self-hosted metrics dashboard for Spring Boot and Quarkus.

Experiment record Questions and comments StatLite on GitHub