Not quite; AOT-compiled, your app won't need the JIT infrastructure, less memory needed for class metadata, etc. In addition, Quarkus pulls many things to build time, which classic frameworks do at runtime, e.g. processing XML metadata descriptors. This means again less classes need to be loaded (or even present) at runtime, as e.g. the XML parser classes won't be part of the native image at all. Also see the numbers on quarkus.io, e.g. 28 MB vs. 145 MB RSS for a REST + CRUD app as native binary vs. HotSpot.
Disclaimer: working at Red Hat, contributing to Quarkus a bit.
I can believe that Quarkus uses a lot less memory than Spring!
But not simply using Graal.
JIT infrastructure, class metadata, etc are real, of course, but they are a small fraction of total memory use in every app i have ever worked on. Okay, you get a small saving by using Graal, so my original comment is not quite right. But it's not going to make the difference between an app needing 256 MB and 238 MB.
There are two aspects, as I understand it: Graal's native image and Quarkus's compile-time evaluation of annotations. Each is responsible for different aspects of space and time saving.
The comparable compile-time effort in Spring is being explored in the spring-init project[0] and I believe will be a core feature in Spring Boot 3 / Spring Framework 6, along with Graal support.
Disclaimer: working at Red Hat, contributing to Quarkus a bit.