You're starting a new Java service in 2026. The requirements look familiar: REST endpoints, a Postgres connection, deployed to Kubernetes, autoscaling on load, and a budget that charges you per megabyte of RAM your pods sit on. Ten years ago there was one obvious answer. Today there are two, and both just shipped major releases.
Spring Boot 4 arrived in November 2025, followed by Spring Boot 4.1 in June 2026, rebuilt on Spring Framework 7 and Jakarta EE 11. Quarkus countered with Quarkus 3.27, its new LTS release, patched as recently as August 2026. Both frameworks now support Java 25, both compile to GraalVM native images, and both claim to be the right home for cloud-native Java.
The marketing from both camps sounds identical. The tradeoffs are not. This comparison breaks down what actually changed in each release, what real benchmarks say about startup time, memory, and throughput, and which framework fits which kind of service.
Full disclosure: the analysis here is based on release documentation, official benchmark data, and independent comparisons cited throughout, not on running both frameworks side by side in a production environment.
What Spring Boot 4 Actually Changed
Modularisation is the headline. In Spring Boot 3.x and earlier, nearly all auto-configuration lived in a single JAR, spring-boot-autoconfigure, and every application loaded all of it. Spring Boot 4 breaks this into 70-plus individual auto-configuration modules, so each starter pulls in only the modules it needs. A Spring team presentation on the restructuring shows the effect on the PetClinic sample app: the monolithic 2.1 MB spring-boot-autoconfigure JAR becomes a 371 KB module, and related actuator and core JARs shrink similarly. Smaller classpaths mean faster startup, smaller native images, and far less noise in IDE autocomplete.
The platform baseline moved, the Java baseline did not. Spring Boot 4 requires Java 17 at minimum, the same as Boot 3, with first-class support for Java 25, the current LTS. There is no javax to jakarta rewrite this time, though the move to Jakarta EE 11 and Servlet 6.1 does real work in the dependency layer. Boot 4 also removes JUnit 4 support entirely, drops Undertow as an embedded server, and makes Jackson 3 the default JSON library, a change that can silently break serialization tests.
Developer experience features arrived in bulk. Native API versioning is now a first-class attribute on @GetMapping and friends, so one controller class can serve multiple API versions without path duplication. @ImportHttpServices turns a declarative HTTP interface into a configured client bean with zero boilerplate. JSpecify null-safety annotations now run across the whole Spring portfolio, and built-in @Retryable and @ConcurrencyLimit annotations cover resilience patterns that previously needed extra libraries.
What Quarkus 3.27 Brings
A fresh LTS with a predictable cadence. Quarkus 3.27 LTS shipped in September 2025 and is supported for 12 months, with the latest patch, 3.27.5.1, landing in August 2026. Feature releases continue in parallel, with 3.28 adding security features and custom Grafana dashboards. The quarkus update command can migrate applications from any 2.x or 3.x version to 3.27, which keeps upgrade pain low.
Compile-time DI remains the core bet. Quarkus performs dependency injection wiring and configuration at build time instead of runtime. No reflection-heavy classpath scanning at startup, no bean post-processing passes. This is the structural reason Quarkus starts fast and compiles cleanly to native images, and it is a design Spring Boot cannot fully copy without breaking its enormous ecosystem.
Virtual threads are now mainstream there too. Quarkus has supported @RunOnVirtualThread for blocking code for several releases, and its virtual thread guide covers running whole applications on Java 21-plus virtual threads. On Java 25 specifically, the Quarkus team confirms applications run without trouble, with a working group cleaning up remaining warnings.
Live reload changes daily workflow. Quarkus dev mode watches your source and hot-reloads changes instantly, including configuration, without a restart. Spring Boot DevTools is good, but Quarkus's live coding goes further, and it is consistently the feature developers cite when they switch.
The Benchmark Numbers That Matter
A standardized 2026 comparison ran a REST API with one Postgres query on a 4 vCPU, 8 GB host. The numbers below come from that benchmark, with build and artifact figures cross-checked against an independent JMeter-based test.
Startup time. In JVM mode, Spring Boot 4 starts in roughly 1.9 seconds while Quarkus 3 starts in about 1.15 seconds. In native mode the gap narrows to 104 ms for Spring Boot versus 49 ms for Quarkus. For a long-running service that starts once a quarter, both numbers are irrelevant. For AWS Lambda or Knative scale-to-zero workloads, halving cold start time is real money.
Idle memory. This is where Quarkus hits hardest in JVM mode: about 150 MB idle versus roughly 250 MB for Spring Boot 4. In native mode it is 45 MB versus 80 MB. If you autoscale dozens of replicas, that difference multiplies directly into your cloud bill. Spring Boot 4's modularisation narrowed this gap versus Boot 3, but did not close it.
Throughput under load. With 200 concurrent users, the comparison flips interestingly. Spring Boot 4 on virtual threads handled around 18,000 requests per second in JVM mode, and 19,000 with WebFlux. Quarkus reactive reached roughly 20,000, or 17,000 in native mode. That is a spread of roughly 10 percent, within the range where JIT warm-up, connection pooling, and your actual query cost dominate the result. Throughput is effectively a tie for realistic services.
Build time and artifact size. The JMeter study measured JVM builds at 20 seconds for Quarkus versus 39 seconds for Spring Boot, and native builds at 9 minutes versus 13 minutes. Native artifacts came out at 75 MB for Quarkus versus 109 MB for Spring Boot. Native compilation costs minutes of CI time either way, which is why most teams should treat native mode as an optimization for specific services, not a default.
Response latency. The same study found Spring Boot's JVM mode slightly ahead on response time and thread efficiency at high load, benefiting from mature JIT optimizations. The honest summary: for a 24/7 monolith or long-lived service, the two frameworks are performance-equivalent in practice. The differences concentrate in memory footprint and cold starts.
Ecosystem: The Gap Nobody Benchmarks
Spring's ecosystem is its moat. The JetBrains 2025 survey puts Spring Boot at 55 to 65 percent of enterprise Java applications. Every enterprise vendor ships a Spring Boot starter first: batch, integration, security, Spring AI for LLM workloads, Spring Cloud for distributed systems patterns. If your problem is unusual, someone has probably already written the Spring integration. Stack Overflow answers, blog posts, and hiring pools all follow that installed base.
Quarkus covers the common core well. REST, Hibernate ORM and Panache, Kafka, Redis, schedulers, observability, and OpenAPI are all first-class. Quarkus even offers Spring API compatibility layers for Spring DI, Spring Web, and Spring Data JPA to ease migration. Where it thins out is the long tail: niche libraries, internal company frameworks, and specialist integrations often assume Spring and need rework.
Team familiarity is worth real money. A framework your team already knows ships features faster than a technically superior one they must learn. This is unglamorous engineering economics, and it usually decides the question before any benchmark does.
Code Reality Check
Both frameworks stay out of your way for a plain REST endpoint. Spring Boot:
@RestController
@RequestMapping("/orders")
public class OrderController {
private final OrderRepository repository;
OrderController(OrderRepository repository) {
this.repository = repository;
}
@GetMapping("/{id}")
public Order get(@PathVariable Long id) {
return repository.findById(id).orElseThrow();
}
}
Quarkus, using Panache for the same repository pattern:
@Path("/orders")
public class OrderResource {
@Inject
OrderRepository repository;
@GET
@Path("/{id}")
public Order get(@PathParam Long id) {
return repository.findById(id);
}
}
The day-to-day code difference is smaller than the marketing suggests. The divergence is in what happens at build time: Spring wires beans at runtime, Quarkus wires them during compilation, and you feel that in startup, memory, and in the occasional Quarkus build-time error when a library does something too dynamic.
Decision Checklist: Which One For Your Next Service
Choose Spring Boot 4 when:
- Your team already knows Spring, or your hiring market is Spring-heavy
- You depend on the long tail of the ecosystem: Spring Cloud, Spring AI, vendor starters
- Services are long-running, so idle memory matters less than ecosystem breadth
- You want the smoothest migration path from an existing Spring Boot 3 codebase
Choose Quarkus 3.27 when:
- Cold starts matter: Lambda, Knative, scale-to-zero, or bursty autoscaling
- You run many small replicas and RAM-per-pod shows up on the invoice
- Live coding and fast dev-mode feedback would materially speed your loop
- The service's dependency list fits inside Quarkus's well-covered core
The pragmatic answer for most teams: if you are on Spring Boot today, upgrading to Boot 4 with virtual threads and, where justified, GraalVM native images closes most of the startup and memory gap without rewriting anything. Migration to Quarkus makes sense for new, small, scale-sensitive services, not as a retrofit of a healthy Spring codebase.
What I'd Watch Next
Spring Boot 4's modularisation is a structural play: it makes future optimization, including better AOT and native support, progressively easier. Quarkus's compile-time DI gave it a head start, and its LTS cadence now feels enterprise-predictable. The frameworks are converging from opposite directions, Spring getting lighter and faster, Quarkus getting broader, which means the decision will keep being about ecosystem fit and team skills rather than raw speed.
Have you run Spring Boot 4 or Quarkus 3.27 in production? What did your memory and startup numbers look like compared to these benchmarks? I'd genuinely like to hear how it went, share your experience in the comments.
I write about Java, Spring Boot, and AI every week. Subscribe, it's free, and it means the next comparison lands in your feed instead of your search results.
Sources: benchmark figures are from the devops-monk 2026 comparison and the besthub.dev JMeter study; release details from Spring Boot 4 coverage by Dan Vega, the Spring IO 2026 restructuring talk, and quarkus.io. Benchmarks vary with hardware and workload, treat them as directional, not gospel.
Top comments (0)