The first announcement was the name itself. What started as an internal evolution of Panache has grown into a broader data-layer effort, so the team wanted a name that is easier to discover and better aligned with the problem space.

Steph explained that “Panache” is memorable if you already know Quarkus, but less obvious for users browsing extensions on code.quarkus.io. “Quarkus Data” is more descriptive and mirrors earlier naming simplifications such as the move to Quarkus REST.

The rename also reflects scope. This is no longer just a new Panache flavor for one backend. The goal is a common umbrella for multiple data technologies and execution styles.

Before getting into the redesign, the discussion acknowledged why Panache became popular in the first place.

Panache made live coding and rapid development much easier by removing a lot of repetitive persistence code. With a typical entity extending a Panache base type, developers got:

That simplicity is still a major design goal. Quarkus Data is not trying to abandon the productivity benefits of Panache; it is trying to keep them while removing some long-standing limitations.

Steph outlined several pain points in the original Panache model.

A major part of the redesign is integration with Jakarta Data, the emerging standard for repository-style data access.

Jakarta Data introduces repository interfaces whose methods can be implemented automatically based on annotations and signatures. In the episode, Steph showed two important styles:

The key benefit is compile-time checking. The annotation processor can verify that referenced entity fields actually exist and that parameter types match. That means fewer broken queries hiding until runtime.

This also opens the door to better IDE support. Steph noted that some support is already visible in IntelliJ IDEA, though still rough around the edges, and the Quarkus team intends to improve this further through the Quarkus language tooling.

The most important architectural shift is that Quarkus Data aims to let developers mix and match several dimensions that used to be separated:

Steph described this as putting the different access modes “on the same pedestal” instead of treating one as the default and the others as second-class options.

One of the most interesting parts of the demo was the distinction between managed and stateless access.

With managed entities, changes are tracked automatically and written back to the database without an explicit update call. With stateless access, the entity is not tracked, so modifications only reach the database when you call update() yourself.

In the prototype shown on the stream, the entity could be switched from a managed form to a record/stateless form with only small code changes. The repository access mode then determined whether updates were implicit or explicit.

That flexibility is powerful, but it also raised a good question from the audience: will mixing these models create a new class of bugs where developers forget whether an update is automatic? Steph’s answer was pragmatic: this is still experimental, and the team wants feedback on whether mixing these modes is genuinely useful in real applications or whether most teams will standardize on one style.

The live demo showed that Quarkus Data is trying to preserve the “easy path” that made Panache attractive.

Instead of calling static methods directly on the entity type, the prototype uses generated metamodel accessors and repositories. From there, developers can still do familiar operations such as:

Steph also showed that repositories can be injected directly, which avoids repeating long generated accessor chains in endpoint code.

At the moment, some of the generated type names are still very much in flux. That was part of the humor of the episode: the functionality is becoming real, but the naming is still being refined.

The demo then moved from convenience methods to Jakarta Data repositories.

Instead of placing custom query logic as static methods on the entity, Steph defined a repository interface extending the appropriate generated repository type. From there, custom methods could be added using Jakarta Data annotations or finder conventions.

This enables a gradual migration path:

That migration story is important. Quarkus Data is not presented as a complete rejection of Panache’s ergonomics, but as a way to evolve toward stronger typing and more flexible architecture.

Another visible change is the move away from Panache-specific paging and sorting types toward Jakarta Data equivalents.

In the demo, sorting and paging parameters were passed directly through REST endpoints using Jakarta Data types such as Order and PageRequest, with support wired through Quarkus REST. That means the data layer and REST layer can speak a more standard vocabulary instead of relying on framework-specific helper classes.

Steph also mentioned cursor-based paging as another mode supported by Jakarta Data, though the episode did not go deep into implementation details.

Reactive support was another major theme.

Rather than forcing developers into a separate reactive Panache universe, Quarkus Data aims to let reactive repositories sit alongside blocking ones. In the demo, Steph created a reactive repository returning Mutiny Uni and showed that the same repository concepts still apply.

That makes it easier to keep most of an application blocking while selectively making certain methods reactive for performance or runtime-behavior reasons. The team sees this as a more realistic adoption path than requiring an all-or-nothing switch.

The episode repeatedly emphasized that this work is not finished.

Steph was candid that the demo depended on several branches not yet merged to main, that names are still changing, and that some IDE behavior and runtime bugs are still being ironed out. Even the package names are expected to change.

The current state is best understood as a serious preview rather than a production-ready recommendation.

That said, the direction is now concrete enough for meaningful feedback. The team is specifically looking for input from:

The live discussion surfaced a few useful themes.

The naming discussion near the end of the episode suggested that Quarkus 3.37 would likely be the first release where users start seeing “Quarkus Data” appear, though with the caveat that package names and type names may still evolve.

Quarkus Data is trying to solve a difficult balancing act:

If the effort succeeds, it could make Quarkus data access both more powerful and more coherent, especially for teams that need more than the original “single happy path” Panache model.

For a project that Steph described as nearly three years in the making, this episode felt like an important milestone: Quarkus Data is no longer just an internal idea or a pile of half-working branches. It is becoming a coherent proposal for the future of data access in Quarkus.

The API is still evolving, and the team is being explicit that now is the time for feedback rather than blind adoption. But the direction is compelling: preserve the developer joy of Panache while adding stronger typing, broader backend support, and a more unified model for modern Quarkus applications.