SpringBoot vs Quarkus: a Real-Life Experiment

Serhii Hainulin
Jan 7 · 8 min read

Despite being a fan of Spring Framework, every now and then I experience a feeling of “stomach heaviness” employing it in the micro-service architecture. Fast to create, a tiny SpringBoot REST API with a mundane business logic and RDBMS connectivity usually encounters up to tens of thousands of classes and consumes 300–500 MB of RAM at runtime. One can argue that memory and computational resources are commodities nowadays and the flip side of the Spring’s cumbersomeness are resilience and stability. While it’s definitely true to some extent, I refuse to believe that stable application can’t be lean and efficient. And that’s where relatively new technologies like Quarkus, Micronaut or Microprofile can be handy to prove.

In Yilu we are developing a complex and modular end-to-end platform for trips that supports travellers by supplying them with the most relevant information about their destinations and bookings, as well as promotes tailored services and attractions that help to make the journey really easy and fun. Our platform is built of micro-services running in the Kubernetes and any of the new lean frameworks can be a good fit for it. Thus planning of next part of the platform spawns the same vicious cycle of doubts about software efficiency vs. introduction of a new technology into the existing tech stack.

I’ve been watching the development of Quarkus and Micronaut for a couple of years already and even applied them in projects. Despite the huge progress and my (mostly intuitive) appreciation of those frameworks, I’m very hesitant to recommend any because of a lack of credibility and acceptance as well as very little practical evidence supporting their benefits. Despite bright and promising assertions of superiority of new frameworks over SpringBoot and each other, existing reviews, guides, and comparisons are mostly based on “Hello world” examples that can hardly benchmark any real life performance and coding experience. Thus I didn’t come up with anything better than to make my own experiment and to find out whether SpringBoot can be easily beaten by one of those frugal frameworks.

Target audience

Key takeaways

  • the overall development experience is comparable. The author had a significant exposure to Spring and almost negligible experience with Quarkus, thus the start of the development indeed required some learning of Quarkus basics, including Mutiny — a reactive programming library that replaced Project Reactor in Quarkus and Vert.x. Nevertheless estimated development time of both versions of the app was pretty equal.
  • Quarkus integrates numerous seasoned technologies (many of them are also employed in Vert.x) so it’s not something entirely new, however, in contrast to the Spring’s projects, these technologies have yet to be aligned to each other. This fact can cause some hiccups during development and, again, requires some learnings and workarounds.
  • App scaffolding for both frameworks is straightforward. Both have web pages where one can configure and scaffold the future app as well as IDE plugins with the similar features.
  • Unfortunately a SpringBoot code can’t be directly ported to a Quarkus app, mainly due to the different technologies that are used to perform similar functions. Nevertheless Quarkus declares integration with SpringBoot projects as well as ability to use the SpringBoot’s CDI mechanism. I’m not sure what consequences this mixture will have for the app efficiency and size, but probably it will result in some compromises.
  • in comparison to Quarkus, SpringBoot has a way better documentation that is pretty handy in development. Most of the problems one can encounter are widely discussed at StackOverflow and GitHub. Quarkus’ documentation in many cases is scarce. Some additional information can be found on websites of corresponding technologies or Vert.x.
  • The technologies employed by Quarkus feel to be “lighter” and more straightforward in use, that compensated a bit the scarcity of documentation.
  • Metrics-wise Quarkus showed a significant superiority for some of the measured indicators:

Basically both apps show a comparable productivity, but the Quarkus’ memory footprint was five times lower than the SB’s one (under a moderate load).

Building the app

Employed technologies

Reactive programming library

The SpringBoot app uses the seasoned Reactor’s Mono and Flux. Polished documentation and widespread usage often make it to be a choice No1 for development of reactive applications.

App config and CDI


SpringBoot doesn’t provide any reference to officially supported GraphQL implementation, thus, after short research, the GraphQL Java Kickstart was picked for the experiment. This library requires an upfront schema definition and some boilerplate code for its implementation.

API client


DB client


  • approx. 2 minutes of retrieving and processing data from an external API (1 HTTP call every 10 seconds);
  • the 2 minutes long load test with progressive scaling from 0 to 100 simultaneous requests to GraphQL API (alongside with continuing data processing of the first stage);
  • the 2 minutes long load test with progressive scaling from 0 to 1000 simultaneous requests to GraphQL API (alongside with continuing data processing of the first stage).

CPU load

Quarkus App CPU load

SpringBoot App:

SpringBoot App CPU load

As graphs show, Quarkus consumes less CPU power during the 1st phase, but causes a significant load responding API calls.

Memory footprint

SpringBoot App’s Heap:

Quarkus App’s Metaspace:

Quarkus App’s Metaspace:

The difference in memory consumption between two frameworks is drastic. Quarkus consumed five times less memory under the moderate load. The memory consumption started to grow only in response to more than 200 concurrent requests. SpringBoot in its turn, outperformed Quarkus when the load reached approximately 700 simultaneous calls.

Http metrics

SpringBoot (0–100 concurrent calls):

Quarkus (0–1000 concurrent calls):

SpringBoot (0–1000 concurrent calls):

(0–1000 concurrent calls)

The average latency of the SB API is 4 times lower than the one of Quarkus. The API scalability was also way better at the SB app.


Memory efficiency of Quarkus is really impressive, it also outperformed SpringBoot in CPU load under a moderate pressure. This article doesn’t cover Graal-VM — a tandem partner, that helps Quarkus to fully shine in its glory. According to some benchmarks usage of Graal-VM helps to improve Quarkus’ metrics and resource consumption even more. This, along with compilation to native app, can be a good ground for another paper.

Pretty weak HTTP metrics of Quarkus most probably were caused by deficiencies of the SmallRye GraphQL library. I conducted a couple of other load tests and intuitive benchmarks (not covered here), that confirmed this guess. But this also proves the fact that some Quarkus technologies are still slack-baked and need to be considered carefully.

As a general conclusion, I would rather abstain from using Quarkus for critical and heavy-loaded applications yet, but definitely give it a try for supportive services.

The Startup

Get smarter at building your thing. Join The Startup’s +746K followers.