How does Quarkus achieve low memory footprint?

Quarkus reduces memory usage through the same build-time philosophy that drives its fast startup: by resolving as much as possible ahead of time, it avoids keeping large amounts of metadata, reflection caches, and unused code in memory at runtime that a traditional framework would otherwise load.

In JVM mode, this shows up as fewer classes loaded, less reflective metadata cached, and lazy initialization used wherever build-time resolution isn't possible, which trims the JVM's baseline heap and metaspace usage compared to a framework that scans and wires everything reflectively at boot.

In native mode, the gains are far larger: GraalVM's static analysis strips out any code path the application can't actually reach, so the resulting binary contains no unused framework internals, and there's no separate JVM process overhead sitting underneath the application at all — the combination is why native Quarkus services commonly run with a fraction of the resident memory of the same application in JVM mode.