Spring Boot vs Quarkus: Performance, Migration, and Real‑World Comparison

Overview

Spring Boot is a mature Java framework for enterprise applications that emphasizes convention‑over‑configuration and rapid development. Quarkus is a newer Kubernetes‑native Java framework optimized for GraalVM native images, offering fast startup and low memory consumption.

Spring Boot

Spring Boot reduces boilerplate, auto‑configures components based on classpath dependencies, and supports both blocking (Servlet) and non‑blocking (WebFlux) web stacks.

Quarkus

Quarkus targets cloud, serverless and container environments. It provides reactive programming support, native image generation via GraalVM, and integrates with popular Java libraries.

Comparison

Both frameworks integrate well with existing libraries, but their internal architectures differ. Spring Boot offers separate blocking and reactive stacks, while Quarkus embeds reactive support directly and can compile to native binaries.

Test application

A small reactive service implements three REST APIs (create, query by postal code, query by city) backed by PostgreSQL. The implementation uses Spring WebFlux for the Spring Boot variant and Quarkus reactive extensions for the Quarkus variant.

Test plan

JMeter runs a 5‑minute load test: a warm‑up phase followed by a ramp‑up to 1,500 concurrent users exercising all APIs. VisualVM records CPU, heap, and thread usage during the run. The hardware used is shown below.

Results

Startup & build time

Quarkus native images start roughly twice as fast as Spring Boot native images. Build times are also shorter:

9 minutes (Quarkus) vs 13 minutes (Spring Boot) for native builds

20 seconds (Quarkus) vs 39 seconds (Spring Boot) for JVM builds

Artifact size

Quarkus produces smaller artifacts: 75 MB (native) vs 109 MB (Spring Boot native) and 4 KB (JVM) vs 26 MB (Spring Boot JVM).

CPU usage

During warm‑up the JVM variant consumes more CPU, but overall CPU usage stabilises across all variants.

Memory usage

Quarkus reserves less heap at startup and shows lower memory consumption during execution. Native images do not reclaim memory as aggressively as JVM images.

Response time & throughput

Spring Boot JVM shows slightly better response times and can handle the same load with fewer threads. Quarkus performs well in low‑resource scenarios. Both frameworks processed all requests without errors and exhibited comparable throughput.

Conclusion

Both Spring Boot and Quarkus are viable for Java microservices. Quarkus native images are ideal for serverless or short‑lived workloads because of their fast startup and low resource usage. Spring Boot JVM offers stable, high‑throughput performance for long‑running services.

Migrating from Spring Boot to Quarkus

Quarkus provides Spring API compatibility (DI, Web, Data JPA) so existing Spring knowledge can be reused while benefiting from Quarkus optimizations.

Why switch?

Reduced memory and CPU consumption.

Much shorter warm‑up time (seconds vs tens of seconds).

Less boilerplate code.

Easy unit and integration testing with @QuarkusTest.

Better horizontal scalability.

Clear documentation and learning curve.

Benefits for Spring developers

FaaS readiness: native binaries can start in ~0.0015 s, enabling use with AWS Lambda, Azure Functions, etc.

Live coding: changes are reflected instantly without restarting the JVM.

Support for both reactive and imperative models in the same application.

Compile‑time detection of CDI injection errors.

Combines the best of Spring, Vert.x, MicroProfile, and reactive streams.

Getting started

Read the Quarkus introductory guide.

Study the Spring DI, Spring Web, and Spring Data JPA guides on the Quarkus site.

Generate a new project at code.quarkus.io and experiment with the examples below.

Code examples

import java.util.List;
import java.util.Optional;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/person")
public class PersonController {
    @GetMapping(path = "/greet/{id}", produces = "text/plain")
    public String greetPerson(@PathVariable(name = "id") long id) {
        String name = "";
        // ...
        return name;
    }

    @GetMapping(produces = "application/json")
    public Iterable<Person> findAll() {
        return personRepository.findAll();
    }
}

package org.acme.springmp;

import java.util.List;
import org.springframework.data.repository.CrudRepository;

public interface PersonRepository extends CrudRepository<Person, Long> {
    List<Person> findByAge(int age);
}

import org.eclipse.microprofile.faulttolerance.Fallback;
import org.eclipse.microprofile.faulttolerance.CircuitBreaker;
import org.eclipse.microprofile.rest.client.inject.RestClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Service;

@Service
public class PersonService {
    @Autowired
    @RestClient
    SalutationMicroProfileRestClient salutationRestClient;

    @Value("${fallbackSalutation}")
    String fallbackSalutation;

    @CircuitBreaker(delay=5000, failureRatio=.5)
    @Fallback(fallbackMethod = "salutationFallback")
    public String getSalutation() {
        return salutationRestClient.getSalutation();
    }
}

References

https://www.baeldung.com/spring-boot-vs-quarkus

https://quarkus.io/blog/quarkus-for-spring-developers/

https://www.logicmonitor.com/blog/quarkus-vs-spring