Red Hat build of Quarkus 3.33 has reached general availability, establishing a new Long-Term Support (LTS) stable baseline for teams that value predictability over chasing every upstream feature drop.
Here is what makes it significant: because Red Hat ships a feature release roughly every six months and our last LTS was 3.27, Red Hat build of Quarkus 3.33 rolls up a subset of the community delivered across 3.28 through 3.33 into one fully supported release focused on enterprise stability. A single upgrade gives you months of data, security, performance, and tooling improvements at once, with a three-year support lifecycle behind it.
Let's take a look at the highlights. For the complete list of new features, enhancements, and technical changes, see the official Red Hat build of Quarkus 3.33 release notes.
Modernizing your data access layer
Data access is the unglamorous foundation underneath almost everything—from event-driven messaging and transactional workloads to streaming pipelines and the data-heavy AI features like retrieval-augmented generation (RAG). This release modernizes that foundation across the board.
Hibernate ORM 7.2, Reactive 3.2, and Search 8.2 all land in this LTS, along with updated Elasticsearch (9.2) and OpenSearch (3.3) clients and Dev Services. The payoff is better query efficiency, refined caching, and more capable indexing, whether you are serving a high-traffic API or the search layer behind an AI assistant. These upgrades carry configuration and API changes, so review the migration guide first.
Jakarta Data integration through quarkus-hibernate-orm continues to mature. Built on the Jakarta EE 11 specification, it gives you a standardized, type-safe way to define repositories and build queries. Extending an interface like CrudRepository drops the CRUD boilerplate, and the generated static metamodel lets the compiler check your sorting and filtering, turning a whole class of query mistakes into build errors instead of production incidents.
Hibernate ORM and Reactive now stay enabled even with no entities defined. Minor until you hit it: you can run native queries and use other Hibernate APIs without inventing a placeholder entity just to keep the extension awake.
Strengthening your application security posture
If you are positioning Java as a reliable, security-focused choice for modern workloads, this is the section to read closely. As teams expose more endpoints and wire up service-to-service calls across distributed systems, fine-grained, security-first control is exactly what production deployments demand.
More precise OIDC control. Several OpenID Connect improvements trade all-or-nothing settings for method- and flow-level control:
- Flow-specific filters scope an
OidcRequestFilterorOidcResponseFilterto the bearer or authorization code flow, so they behave predictably when both are enabled. - Per-method token propagation lets one REST client propagate a token only on its authenticated methods, leaving public ones untouched.
- Method-level
@OidcClientFilterbindings apply token handling to specific methods, not the whole interface.
Scheduled tasks can now run with a security identity. Annotate a @Scheduled method with @RunAsUser to assign a user and roles, so background jobs can finally call your @RolesAllowed services without awkward workarounds.
Security hardening raises the floor. The TLS registry now enables TLS 1.3 only by default, and the Elytron properties-file store defaults to SHA-512 hashing instead of MD5. These are deliberate hardening choices. They also mean a peer that only speaks TLS 1.2, or a credentials file full of MD5 hashes, needs an explicit configuration change, so check the migration guide before rolling forward.
Accelerating startup performance with Java 25 and Project Leyden
Full Java 25 support arrives in this LTS, so you can build and run on the latest Java LTS and standardize your fleet on it, picking up the performance, language, and security gains that come with it.
Project Leyden ahead-of-time (AOT) caching lands as a technology preview in this release, fundamentally changing how the platform handles initialization work.. The build records an ahead-of-time cache that your application reuses at runtime to skip repeated startup work, meaningfully reducing JVM warm-up time and narrowing the historical gap between JVM and native mode. Faster startup is more than a nicety: when you scale inference or model-serving workloads up and down, quicker cold starts translate directly into better responsiveness and reduced infrastructure cost. Leyden AOT caching requires Java 25.
Simplifying developer experience and build tooling
Quarkus has always aimed to bring joy to Java development, and this release continues that mission.
Multiple cache backends per application. Assign a different backend to each cache in the same application, for example Caffeine for hot local data and Redis for distributed state. You are no longer locked to one backend per application, so you can use the right tool for each job.
A new quarkus Maven packaging and lifecycle. Setting <packaging>quarkus</packaging> switches to a Quarkus-specific lifecycle that skips Maven steps adding no value for a Quarkus application, such as producing the default jar, for a cleaner, faster build. If you rely on an uber-jar or the default install and deploy steps, keep jar packaging or configure them explicitly.
AOT cache generation during integration tests. @QuarkusIntegrationTest can now produce the ahead-of-time cache as part of the test run, so you get it without a separate build step.
Hibernate Validator 9.1 brings faster validation, including better cascading validation across object graphs, which adds up on request-heavy services.
Exploring upcoming capabilities in technology preview
Beyond Leyden AOT caching, this LTS introduces two more previews worth experimenting with:
- Hibernate Spatial is now available as a managed dependency, adding support for spatial data types and queries (with both JTS and Geolatte geometry models) for location-aware applications.
- Kafka request-reply support, via SmallRye Reactive Messaging, lets you send a request to a Kafka topic and asynchronously await a correlated reply through the
KafkaRequestReplyemitter, bringing a request-response pattern to event-driven systems.
As technology preview features, these are not covered by production SLAs, but they are a great way to get ahead of what is coming and to give us feedback.
Upgrade today
Migrating to Red Hat build of Quarkus 3.33 should be smooth: there is a migration guide and automated tooling to do most of the work. Update to the latest Quarkus command-line interface (CLI) and run:
quarkus updateThe quarkus update command can move an application from virtually any earlier version, even 2.x, and handles most of the heavy lifting automatically. A few cases still need a manual touch, so read the relevant guides before you ship. How much there is to do depends on where you start:
- From 3.32? Nothing to do, as Red Hat build of Quarkus 3.33 LTS is its direct continuation.
- From the previous LTS, 3.27? Work through the community migration guides for 3.28, 3.29, 3.30, 3.31, and 3.32. The 3.33 guide is intentionally empty.
Because this LTS spans several community releases, it includes a number of backward-compatibility changes. Rather than list them here, review the Changes that affect compatibility with earlier versions and Deprecated components and features sections of the release notes before upgrading.
Try Quarkus
The best way to experience the new features is to start using them. You can generate your project at code.quarkus.redhat.com.
You can find more Quarkus resources on Red Hat Developer:
