Spring Boot vs. Quarkus auf einem 512-MB-VPS: Der Speicher zählt mehr als das Framework-Marketing

Java auf einem 512-MB-VPS ist kein akademischer Sonderfall. Für kleine interne Dienste, Side Projects, Admin-Tools oder günstige Edge-Deployments ist genau das die Realität. Umso interessanter ist der direkte Vergleich zwischen Spring Boot 3.5 und Quarkus 3.39 unter JDK 25, beide als normale JVM-Anwendungen, ohne Native Image, mit identischer Last, H2, -Xmx80m, Serial GC und gleicher JVM-Abstimmung.

Die Kernaussage ist klar: Quarkus lag beim Resident Set Size unter Druck niedriger, obwohl es anfangs größer startete. Das ist keine Kleinigkeit. Auf einer Maschine mit 512 MB RAM entscheidet genau dieses Verhalten darüber, ob ein Dienst ruhig durchläuft oder bei Lastspitzen ungemütlich wird.

Wichtig ist aber auch, was dieser Vergleich nicht hergibt. Er beweist nicht, dass Quarkus in jeder Java-Umgebung automatisch die bessere Wahl ist. Er zeigt etwas Konkreteres: Wenn der Speicher brutal knapp ist, können Unterschiede im Laufzeitverhalten wichtiger sein als der übliche Framework-Geschmack im Team.

512 MB sind eine ehrliche Grenze

Viele Framework-Debatten laufen an der Praxis vorbei, weil auf Entwicklerrechnern und üppigen Cloud-Setups getestet wird. Dort fallen 50 oder 100 MB mehr kaum auf. Auf einem kleinen VPS ist das anders. Da konkurrieren Framework, JVM, Datenbank im Prozess, Betriebssystem und Nebenjobs direkt um jeden freien Bereich.

Genau deshalb ist ein Test mit identischer Anwendung und gleicher JVM-Basis interessant. Nicht, weil er die Java-Welt abschließend bewertet. Sondern weil er eine Frage beantwortet, die in kleinen Setups sehr konkret ist: Welches Framework bleibt unter realem Speicherdruck berechenbarer?

Quarkus punktet hier beim Speicherbild unter Last

Dass Quarkus zunächst größer startet und später eine kleinere residente Speichernutzung zeigt, ist ein Hinweis auf das, was Betreiber in der Praxis sehen wollen: nicht bloß hübsche Startwerte, sondern stabiles Verhalten im Betrieb. Gerade auf kleinen Maschinen zählt nicht der Peak beim Hochfahren allein. Entscheidend ist, was ein Dienst nach einigen Requests, Caches, Datenbankzugriffen und Hintergrundarbeit tatsächlich dauerhaft im RAM hält.

Wenn Quarkus in diesem Szenario niedriger bleibt, ist das ein echter Vorteil. Nicht als Marketingfolie, sondern als operative Reserve. Diese Reserve kann darüber entscheiden, ob zusätzlich noch ein Reverse Proxy, Monitoring-Agent oder ein zweiter kleiner Dienst auf denselben Host passt.

Für Spring Boot ist das keine Niederlage, aber ein Warnsignal für kleine Deployments

Spring Boot bleibt für viele Teams der pragmatische Standard. Das Ökosystem ist riesig, die Bibliothekslage stark, die Entwicklerbasis groß. Daran ändert so ein Vergleich nichts. Wer genug RAM hat, wird den Unterschied oft kaum im Alltag spüren.

Auf 512 MB sieht die Rechnung nüchterner aus. Dann kostet Komfort schneller echtes Geld oder Betriebsspielraum. Wer Spring Boot auf so kleinen Instanzen einsetzt, muss Tuning ernster nehmen. Heap-Limits, Garbage Collector, Autokonfigurationen, Abhängigkeiten und die Frage, was im Prozess wirklich mitlaufen muss, sind dann keine Feinarbeit mehr. Sie sind Teil der Architektur.

JDK 25 macht den Vergleich aktueller als viele ältere Java-Debatten

Der Test ist auch deshalb interessant, weil beide Frameworks mit JDK 25 auf derselben Basis laufen. Viele ältere Diskussionen zu Spring Boot gegen Quarkus stammen aus einer Zeit, in der Java bei Speicherverbrauch und Startverhalten noch ein anderes Bild abgegeben hat. Neue JDK-Versionen verschieben solche Vergleiche regelmäßig.

Das heißt aber auch: Wer noch mit alten Annahmen arbeitet, liegt schnell daneben. Aussagen wie „Spring ist immer zu schwer“ oder „Quarkus lohnt nur als Native Image“ greifen zu kurz. Schon als reine JVM-Anwendung kann Quarkus unter engen RAM-Grenzen einen handfesten Vorteil haben.

Die eigentliche Lehre: Kleine Server bestrafen Nachlässigkeit

Der Vergleich erzählt am Ende weniger von Ideologie als von Disziplin. Auf einem 512-MB-VPS gibt es keinen Platz für gedankenlose Defaults. Wer dort Java betreibt, muss bewusst bauen: schlanke Abhängigkeiten, begrenzter Heap, klare Lastprofile, saubere Beobachtung des Resident Set statt nur des Java-Heaps.

Genau hier ist der Test wertvoll. Er verschiebt die Debatte weg vom üblichen Framework-Lagerdenken und hin zur Betriebsrealität. Quarkus hat in diesem Setup das bessere Speicherbild gezeigt. Für Teams mit harten RAM-Grenzen ist das ein starkes Argument. Für alle anderen ist es eine Erinnerung daran, dass moderne Java-Frameworks heute näher beieinander liegen, als es viele alte Reflexe vermuten lassen.

Wer günstig deployen will, sollte diese Art von Vergleich ernst nehmen. Nicht jedes Projekt braucht Quarkus. Aber jedes Projekt auf 512 MB braucht Ehrlichkeit beim Ressourcenbedarf.