Spring Boot vs Quarkus: Performance, Native Images, and Migration Guide

Spring Boot

Spring Boot is a Java‑based framework focused on enterprise applications. It integrates all Spring projects and provides many out‑of‑the‑box features to boost developer productivity.

It reduces configuration and boilerplate code. Its “convention over configuration” approach automatically registers default settings based on dependencies, shortening development cycles.

Quarkus

Quarkus is a Kubernetes‑native Java framework optimized for cloud, serverless, and container environments. It offers faster startup, better resource utilization, and smaller artifacts (Supersonic, Subatomic).

Quarkus supports both blocking (Servlets) and non‑blocking (WebFlux) models and embeds a reactive programming model.

Comparison

Both frameworks integrate well with other projects, but their internal architectures differ. Spring Boot provides two web stacks: blocking (Servlets) and non‑blocking (WebFlux). Quarkus also supports both, allowing simultaneous use, and adds a reactive core.

To obtain comparable data we built two fully reactive applications using Spring WebFlux and Quarkus reactive features, with PostgreSQL as the database. We also created native images using GraalVM; Quarkus native support is mature, while Spring native is still experimental.

Test Application

The sample implements three APIs: create a postal code, query a specific postal code, and list postal codes by city. The goal is a slightly more complex example than a simple Hello World program.

Test Plan

We run JMeter tests for 5 minutes, warming up the database, then increasing concurrent users up to 1,500. VisualVM monitors resource usage during the run.

All tests were executed on a machine with the specifications shown below.

Key findings:

Quarkus starts up almost twice as fast as Spring Boot in both JVM and native modes.

Build time for native images: 9 min (Quarkus) vs 13 min (Spring Boot); JVM build: 20 s (Quarkus) vs 39 s (Spring Boot).

Artifact size: native Quarkus 75 MB vs Spring Boot 109 MB; JVM size: 4 KB (Quarkus) vs 26 MB (Spring Boot).

CPU

During warm‑up the JVM version consumes more CPU, after which usage stabilizes across all versions.

Memory

Both JVM versions reserve more heap memory, but Quarkus reserves less from the start and shows lower memory utilization during startup.

Native Quarkus exhibits higher peak memory usage but overall consumes less memory than the JVM versions.

Response Time

Spring Boot shows a slight advantage in response time and uses fewer threads to handle the same load.

Overall, both frameworks handle all requests without errors and exhibit comparable performance.

Conclusion

Both Spring Boot and Quarkus are solid choices for Java applications. Native Quarkus programs are fast and resource‑efficient, making them ideal for serverless, short‑lived, or resource‑constrained environments. JVM‑based applications, especially Spring Boot, offer higher stability and throughput for long‑running services.

From Spring to Quarkus

Quarkus was created by engineers with deep Java expertise, ensuring strong Spring API compatibility. Migration is straightforward because Quarkus supports Spring DI, Spring Web, Spring Data JPA, and plans to add Spring Security and Config.

Why a Spring Developer Should Choose Quarkus

Containerization and Kubernetes are driving a reevaluation of Java for cloud‑native workloads. Traditional Java runtimes add extra layers, increasing memory consumption and startup time. Quarkus optimizes memory usage and startup speed, delivering up to twice the number of instances on the same RAM and up to seven times more when compiled to native binaries.

Benefits for Spring Developers

Function‑as‑a‑Service (FaaS): native binaries start in ~0.0015 s, enabling seamless integration with AWS Lambda, Azure Functions, etc.

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

Support for both reactive and imperative models.

Compile‑time detection of dependency‑injection errors.

Combination of best‑in‑class frameworks and standards (Spring API, Vert.x, MicroProfile, reactive streams, messaging).

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.Timeout;
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();
    }
}

Additional Advantages for Spring Developers

FaaS integration with native binaries.

Live coding without restarts.

Support for both reactive and imperative programming models.

Early detection of DI errors at compile time.

Seamless combination of Spring API compatibility, Eclipse Vert.x, MicroProfile, and reactive streams.