Quarkus 4 is no longer a rumor. The main branch of the Quarkus repository already builds Quarkus 4, Beta 1 is due this September with a feature freeze for breaking changes, and GA is targeted for November 2026. That is the same month Spring ships Spring Boot 4.2.
Two of the most widely used Java backend frameworks are pushing major releases into the same window. One of them is rebuilding its entire I/O core. The other is shipping new messaging support. If you run backend services on the JVM, the next few months decide which defaults you will live with for years.
I have not migrated anything to Quarkus 4. Nobody has, outside the Quarkus team, because Beta 1 is not out yet. What follows is a breakdown from the official sources: the Quarkus 4 progress report from July 2026, the Quarkus 3.32 release post, and the Spring Boot 4.0 and 4.1 release documentation. Every claim links back to one of them.
Two release trains, two very different loads
The cadence difference is the first thing that jumps out, and it shapes everything else.
Spring Boot 4.0 shipped on November 20, 2025, built on Spring Framework 7. Spring Boot 4.1 followed on June 10, 2026. Spring Boot 4.2 is targeted for November 2026. Two releases a year, roughly May and November.
Quarkus ships monthly point releases. Version 3.39 landed on August 26, 2026, and 3.40 LTS is planned for September 2026 as the last feature release on the 3.x line, with community maintenance running to September 2027. Quarkus 4.0 Beta 1 follows in September, then GA in November.
What that means in practice:
- Quarkus iterates in public. Experimental features land in monthly releases first. Signal, the new event bus, is already available in Quarkus 3 as an experimental feature. Project Leyden AOT support landed in 3.x before Quarkus 4.
- Spring batches its changes. Features arrive in large drops. Spring Boot 4.1 alone brought gRPC auto-configuration, HTTP client SSRF mitigation, Kotlin 2.3, lazy datasource connections, and async context propagation for @async methods in a single release.
- Breaking changes cluster differently. Quarkus flags severe breaking changes, like Jackson 3, well ahead of Beta 1. Spring concentrates them at major version boundaries, like the Jakarta EE 11 baseline and Jackson 3 move in 4.0.
If you hate surprise deprecations, Quarkus warns you months early. If you hate chasing monthly upgrades, Spring's rhythm is easier to plan around.
Startup speed: the gap is closing from both sides
Quarkus built its reputation on fast startup and low memory, largely through native compilation with GraalVM. Spring Boot spent years being the slow one. That story is changing.
Quarkus 3.32 integrated Project Leyden AOT optimizations, which let the JVM record class loading and linking during a training run and reuse an AOT cache afterward. The numbers from the Quarkus 3.32 release post:
- A minimal REST app drops from 370 ms to 80 ms startup.
- A large REST CRUD app with 9,000 classes drops from 3 seconds to 900 ms.
That is on a plain JVM. No GraalVM native image, none of the native-image tradeoffs around reflection configuration, build times, or peak throughput.
Spring Boot 4.1 answers with lazy JDBC connections, so the datasource does not initialize until first use, and async background JPA bootstrap through the new spring.jpa.bootstrap property, which cuts startup time for applications with large JPA models. Spring Modulith and the Boot 4 modularization work reduce what loads at startup in the first place.
The honest comparison for 2026:
- Raw startup: Quarkus still wins, and its JPMS-based JLink work in Quarkus 4 aims at smaller container images with a reduced attack surface too.
- Startup without leaving the standard JVM: Quarkus's Leyden integration is ahead, but both frameworks are converging on the same underlying OpenJDK mechanism, so expect this gap to keep shrinking.
- Memory footprint: Quarkus keeps the edge, especially in native mode. Spring Boot 4's smaller modular jars narrow it for typical web services.
If startup is your pain point because you scale pods aggressively or run serverless, Quarkus remains the stronger pick. If you start twice a day during development, this whole section matters far less than you think.
The I/O core: Quarkus is rewriting its foundation
The biggest architectural story in Quarkus 4 sits underneath everything else. The upgrade to Vert.x 5.1.2 and Netty 4.2 is complete, per the July progress report, and it was substantial: the core I/O layer is fully migrated and functional.
On top of that new foundation:
- HTTP/3 support is implemented and ships as experimental in the first Quarkus 4 release.
- Native transports now cover both epoll and io_uring.
- Domain sockets work without native transports.
- Signal, the new event bus, unifies CDI events, Vert.x events, and internal messaging, and replaces the Vert.x event bus in Quarkus 4.
- Context propagation through reactive pipelines, virtual threads, and the event loop is being reworked as one of the larger architectural changes.
Spring Boot 4 did its own foundational reset a year earlier: a complete modularization of the codebase, JSpecify null safety across the portfolio, and a Kotlin 2.2 baseline. Spring Boot 4.1 added async context propagation for @async methods, the same theme of making context flow correctly across execution models.
Both frameworks are solving the same problem, virtual threads meeting reactive I/O, with different philosophies. Quarkus is rebuilding the eventing layer from scratch. Spring is standardizing what already exists.
AI features: both picked LangChain4j, Spring also has its own
This is where the 2026 roadmap overlap gets interesting. The Quarkus 4 progress report describes a major non-blocking rewrite of LangChain4j underway, introducing end-to-end reactive support across models, chat memory, guardrails, and tools, integrating deeply with Quarkus's reactive core and virtual thread model. Quarkus's own agentic patterns are being revamped on top, and MCP server 2.0 supports both stateful and stateless interactions with the new MCP Java annotations.
Spring runs a two-track strategy. Spring AI ships as its own project alongside Boot, and the framework-level story includes HTTP service clients and built-in resilience like retry and concurrency throttling in the 4.0 generation. Sébastien Deleuze, a Spring Framework core committer, noted recently that he now splits his time between Spring Framework and Spring AI.
The comparison:
- Quarkus bets on the community LangChain4j stack plus first-party MCP support. Reactive end to end fits its core.
- Spring backs its own Spring AI, which integrates with Boot's observability, security, and configuration conventions out of the box.
- Neither framework treats AI as a bolt-on anymore. Both are wiring model calls into their core execution models, which tells you where Java backend work is heading.
If you want LangChain4j specifically, Quarkus 4's deep integration will be hard to beat. If you want AI features to inherit your existing Boot observability and security setup, Spring AI is the lower-friction path.
Persistence and data access
Quarkus 4 upgrades to Hibernate 8 and finalizes Quarkus Data, the next generation of Panache, which aligns with the Jakarta Data standard and adds type-safe queries via Hibernate Processor annotations. It is shipping experimentally now, with finalization planned for GA.
Spring Boot 4 stays on the standard Spring Data stack. Jakarta EE 11 is the 4.0 baseline, and Spring Data 2026.1.0 milestones add Redis JSON support through a new RedisJsonTemplate.
One practical note: Spring Boot 4.1 deprecated the Apache Derby integration after the Derby project retired, so teams on Derby need to migrate regardless of framework.
The decision matrix
Here is how I would pick in September 2026, based on everything above:
- Greenfield microservice where fast cold start matters (scale-to-zero, serverless, dense scheduling): Quarkus. The Leyden numbers are real, and Quarkus 4 pushes further with JLink images.
- Existing large Spring Boot codebase: Spring Boot 4.x, without hesitation. The migration tooling, OpenRewrite recipes, and Jackson 2 compatibility module exist precisely for you. Rewriting to Quarkus is a business decision, not a technical one.
- New service in a Spring shop: Spring Boot 4.1. Team knowledge outweighs the Quarkus advantages for most teams.
- Heavy reactive or event-driven workloads: Quarkus 4 looks stronger on paper, with the new Vert.x 5 core, HTTP/3, io_uring, and the Signal event bus. But it is a beta, and beta means beta.
- AI-heavy roadmap in Java: Both are credible. LangChain4j plus Quarkus if you want the reactive route, Spring AI if you want convention-over-configuration integration.
- Stability above all: Quarkus 3.40 LTS in September 2026, supported to September 2027, or Spring Boot 4.0.x, which has open-source support until December 31, 2026. Note that date: Spring Boot 4.0 loses free patches at the end of this year, so new projects should start on 4.1.
The underrated factor is risk. Quarkus 4 is the bigger leap: a new I/O core, a new event bus, Jackson 3, a likely Java 21 baseline still under discussion. Bigger leap, bigger payoff, bigger chance that a feature you depend on shifts before GA. Spring Boot 4.2 in November is an incremental release on a foundation that has been stable since last November.
What I would do in the next 90 days
- If you run Quarkus in production: plan your 3.x to 3.40 LTS upgrade now, and read the Quarkus 4 progress report before Beta 1 lands. The Jackson 3 and event bus changes will touch most real applications.
- If you run Spring Boot 3.5: your open-source support already ended on June 30, 2026. Move to 4.x this quarter, not next year.
- If you are starting fresh: generate both. One Quarkus 4 Beta service, one Spring Boot 4.1 service, same requirements. You will know within a week which one fits your team.
I write about Java, backend engineering, and AI infrastructure every week. Subscribe, it is free.
Which framework is your team standardizing on for 2027, and what is holding you back from the other one? Tell me in the comments.
Top comments (0)