How the Quarkus Ecosystem Grew Over Seven Years

How the Quarkus Ecosystem Grew Over Seven Years

What release history, community extensions, and long-term support mean for the Java applications you maintain.

Markus Eisele

Oct 28

I wanted to look at how Quarkus has changed over the last seven years. Here on The Main Thread, I usually write about one part of it: how to configure an application, test a service, or connect to another system. When you follow these things separately, it is easy to miss how much has changed around them.

So I started with Quarkus release history and a snapshot of the repositories in Quarkiverse, collected on September 30, 2026. The recorded Quarkiverse repository releases went from 688 in 2024 to 922 in 2025, a rise of 34%.

Of course, counting releases only tells us how often something was released. As developers, we also want to know what we can do with it. We need a database connection, integrations with other systems, and a way to keep our applications up to date. Over these seven years, Quarkus has added help with more of these tasks.

Changes that became part of everyday development

When Quarkus was introduced in March 2019, much of the discussion was about Java in containers, fast startup, and using less memory. Live coding was there from the beginning, too. These are still good reasons to look at Quarkus, especially when your application needs to start quickly or run with limited resources.

But quite a few of the changes since then help you during development, including when you run your application on the JVM.

Take Dev Services, introduced in Quarkus 1.13 in March 2021. If your database is supported, Quarkus can start a container and configure the connection for development and testing. You need a working container environment, such as Podman. You also need to leave the external connection unconfigured for this automatic setup to apply. The Dev Services guide explains the details.

This means you can check out an application and start using its database with less separate setup steps. You still need to configure production properly. For local development, though, you can let Quarkus do something that used to need its own instructions in the project README.

Three months later, Quarkus 2.0 added continuous testing. Enable it in dev mode and Quarkus runs tests as you change the application, selecting the relevant tests where possible. You can see a failure while you still have the code in front of you. The full CI build is still needed, but you may find the problem before you push the change.

Then came Quarkus 3.0 in April 2023, with Jakarta EE 10, Hibernate ORM 6.2, and a new Dev UI. Moving to jakarta.* meant changes to application code and dependencies. Quarkus provided quarkus update to help with the migration, along with documentation for the changes that needed more attention.

I would count this as one of the project’s achievements. Most teams have applications they need to keep running while the Java ecosystem changes around them. Tools and migration guides help them make those changes. There is still code to check and testing to do, but the team has a place to start.

I wrote about some of these things in my earlier article on hidden Quarkus features. It is easy to overlook a feature when you don’t need it at the time. Several years later, there may be quite a few things in the framework that could make your application easier to develop.

Quarkiverse gave integrations room to grow

The Quarkiverse Hub explains why community extensions needed a separate home. Keeping every extension in the main Quarkus repository added maintenance, and some projects needed to release on their own schedule. Quarkiverse gives these projects shared infrastructure for their repositories, builds, and releases. Each project still has its own maintainers.

The September snapshot contains 217 repositories, including extensions, tools, and shared infrastructure. Across 162 of these repositories, the recorded GitHub histories contain 3,164 releases. These counts need a little care: one repository can publish several extension artifacts, and some repositories provide infrastructure. The snapshot tells us about the repositories in this organization. It doesn’t give us the size of the whole Quarkus extension catalog.

Looking at complete years, recorded releases grew from 109 in 2021 to 922 in 2025. The count increased every year in between. Some releases add features, others fix problems or keep an extension working with a newer Quarkus version. We need to read individual releases to know which is which, but we can see that these projects have continued to release over several years.

You can also see how different the integrations are. Quarkus CXF supports SOAP services, which an existing business application may need for many more years. Quarkus Amazon Services connects applications to AWS services. Quarkus LangChain4j and MCP Server help build applications that use language models and tools.

Your application may need an old SOAP service and a new AI feature at the same time. Before building either integration yourself, you can check what is already available. Read the extension’s documentation, check which versions it supports, and look at how it is maintained. Those details belong in the decision to add it as a dependency.

A release process you can plan around

More releases also mean more things for application teams to check. Someone needs to read what changed, run the tests, and decide when to update production. If you maintain several services, you need a schedule you can follow.

Quarkus announced community Long-Term Support releases in July 2023, starting with the 3.2 series. Teams could choose an LTS version and receive fixes while staying on that version for longer.

The current release policy describes a minor release every four to six weeks and a new LTS release every six months. Community LTS versions receive critical fixes and security patches for twelve months. Non-LTS versions receive support until the next minor release. Commercial support has its own terms.

So you have a period you can plan around. You still need to apply patches and test upgrades, but you can decide when to move to a newer version within that maintenance period. That is easier to discuss with a team than an open-ended plan to update sometime later.

Extension authors have help with this, too. Ecosystem CI lets them test against the latest Quarkus snapshot each day. Projects that take part can find compatibility problems before the next release. The extension maturity matrix describes things an extension author should consider, including dev mode, native execution, configuration, and observability. It is a guide for development; you still need to check what a particular extension supports.

This helps extensions keep up with Quarkus even when different people maintain them. For an application dependency, I would check whether its project uses these tests and how it handles new Quarkus versions.

Growth also needs somewhere to continue

Quarkus announced its move to Commonhaus in July 2024 and now describes itself as a member of the foundation. The goal was to give the project a neutral home where contributors and organizations beyond Red Hat could take part.

For me, this belongs into the story of how Quarkus has grown. The project needs people who can keep contributing, and a foundation provides a shared home for them. Maintainers still need to review changes, investigate failures, and decide what they can support.

A release history shows some of those contributions. Each release means somebody prepared something for other people to use. There is also documentation, investigation of issues, and time spent helping another developer reproduce a problem. Much of that never produces a release tag, but the project needs it just as much.

What we can see about usage

We also have some information about usage. The published summary of Quarkus Insights 253 reports that monthly active users in its opt-in build analytics grew 16%, and total builds grew 26%, comparing May 2026 with May 2025. New-user numbers stayed flat over the same comparison.

These numbers describe the developers who take part in the analytics. Because participation is voluntary, we cannot use them to calculate Quarkus’s share of the Java market. We can say that this group had more monthly active users and more builds than a year earlier.

The Ship.Cars article from April 2024 gives an example of how a team used the extension model. Its author describes building internal extensions to handle configuration incompatibilities and maintenance problems with native images. The team could put what it had learned into extensions and reuse it in its applications.

If you are considering Quarkus, I would read examples like this alongside the performance measurements. You will also need to understand and maintain the application after it is running in production.

A note on the numbers

The analysis uses a snapshot collected from GitHub end of September, 2026. I recalculated the totals from that dataset. The Quarkiverse chart counts GitHub release objects in the histories of repositories present in the snapshot, including infrastructure projects. Repositories that were deleted or moved can leave gaps in our view of earlier years.

The core dataset contains 525 tags, including prereleases and tags that were never publicly shipped. Its dates come from the underlying commits, so I used public announcements for the milestone figure. The contributor data had limits in how people were sampled and accounts were linked. Release counts also cannot tell us how many people use Quarkus or how many applications run in production.

What is planned for Quarkus 4

There is already quite a bit of public information about Quarkus 4: Quarkus 4 will require Java 21 or newer. If your application still runs on Java 17, you will need to update the JDK before moving to Quarkus 4. Quarkus 3 already supports virtual threads. The new minimum lets Quarkus use Java 21 APIs directly and removes some of the extra code and testing needed to support older Java versions.

The July progress report says the development branch had moved to Vert.x 5.1.2 and Netty 4.2. HTTP/3 was implemented, with experimental status planned for the first Quarkus 4 release. Quarkus Data follows Jakarta Data and uses Hibernate Processor annotations for type-safe queries. The plan is to finish it for Quarkus 4 GA.

The public roadmap targets November 2026 for general availability and March 2027 for the first Quarkus 4 LTS release. These are planned dates and can change. For a team following LTS releases, the second date is probably the one to keep in mind when discussing an upgrade.

For now, you can look through the Quarkus 4 migration guide. Along with the Java requirement, it lists deprecated configuration properties that are being removed and their replacements. Checking your JDK and configuration gives you somewhere to start preparing, even while the release is still being developed.

What I would take into the next application

If you are looking at Quarkus now, start with the integrations your application needs. Check their supported versions, tests, and maintenance. Then try them with your application and decide how often your team can manage upgrades. If you already use Quarkus, this may also be a good time to look at what has been added since you last checked.

Looking back over seven years, I see more of the things a Java team needs being available directly in Quarkus or its extensions. Starting a database for development, running tests while changing code, updating an application, and connecting to other systems all have support that has grown over time. People across the community have built and maintained those parts. Before writing the next piece yourself, have another look at what they have made available. You may already have what you need.

Thanks for reading The Main Thread! Subscribe for free to receive new posts and support my work.

Subscribed

Thank you for reading.

If this piece was useful, sharing it is the simplest way to support the work and help others find it.

Thoughts and corrections are always welcome. I read every comment.

If this email was forwarded to you, you can subscribe to receive future issues directly.

Write boring code. Ship exciting systems.

Subscribed

© 2026 Markus Eisele
🇩🇪