Next-Level Persistence in Jakarta EE: How We Got Here and Why It Matters

Enterprise Java persistence has never really been about APIs. It has always been about assumptions. Long before frameworks, annotations, or repositories entered the picture, the enterprise Java ecosystem was shaped by a single, dominant belief: persistence meant relational databases. That assumption influenced how applications were designed, how teams reasoned about data, and how the Java platform itself evolved.

This article is inspired by a presentation given by Arjan Tijms, director of OmniFish, titled “Next-level persistence in Jakarta EE: Jakarta Data and Jakarta NoSQL.” Delivered in 2024, the talk offers a clear and pragmatic view of why Jakarta EE persistence needed to evolve, how Jakarta Data fits into the platform, and how it relates to Jakarta Persistence and Jakarta NoSQL. While the presentation provides the technical backbone, this article expands on the historical context and architectural motivations behind that evolution.

When Java entered the enterprise world, relational databases were already well established, operationally understood, and widely trusted. It was therefore natural that early persistence efforts focused on SQL-based systems. JDBC provided low-level connectivity, and later Jakarta Persistence (JPA) formalized object–relational mapping as the primary way to bridge object-oriented code and relational schemas. For transactional systems with stable schemas and strong consistency requirements, this approach worked extremely well.

Over time, JPA became so successful that it effectively defined what “persistence” meant in enterprise Java. Persistence was treated as an ORM problem, and the database was implicitly assumed to be relational. For many years, this assumption held true, and there was little incentive to challenge it.

That changed as systems began to scale.

The Rise of NoSQL and Polyglot Persistence

As enterprise applications grew more distributed and data-intensive, new requirements emerged that did not always align well with relational databases. Horizontal scalability, flexible schemas, low-latency access, and data models optimized for specific access patterns became increasingly important. This shift led to the rise of NoSQL databases, including document stores, key-value stores, column databases, and graph databases, each designed to excel in a particular context rather than to serve as a universal solution.

From this diversity emerged the idea of polyglot persistence. Instead of forcing all data into a single model, architects began selecting the most appropriate database for each part of the system. The analogy is linguistic rather than technical: a polyglot speaker chooses the best language depending on the context. In the same way, a system might use a relational database for financial transactions, a document store for evolving aggregates, and a key-value store for high-throughput lookups.

While this approach gained traction architecturally, enterprise Java lagged behind at the platform level.

There was even a public promise around Java EE 7 to include NoSQL integration as part of the standard platform. That promise, however, never materialized. As a result, developers who wanted to use NoSQL databases were forced to rely on vendor-specific APIs, framework-level abstractions, or entirely separate programming models. Persistence in Java became fragmented, with little guidance on how different approaches should coexist.

This gap eventually triggered a community-driven effort to bring NoSQL back into the Java standard ecosystem.

On July 14th, 2016, Otávio Santana proposed a project to reintroduce NoSQL integration into enterprise Java. Initially named Diana and targeted at the Apache Software Foundation, the project was motivated by a simple observation: persistence in Java had become too tightly coupled to relational assumptions. When Java EE transitioned to Jakarta EE under the Eclipse Foundation, the project followed. It was renamed Eclipse JNoSQL and officially moved to the Eclipse Foundation on November 10th, 2016.

The initial ambition was broad, aiming to define common abstractions across very different NoSQL databases. Over time, however, the scope was deliberately reduced. Instead of attempting to standardize everything, the focus narrowed to areas where meaningful commonality actually exists, such as mapping and basic access patterns. That reduction was not a failure; it was a necessary architectural decision. After several years of iteration, Jakarta NoSQL reached its first official release on March 27th, 2024.

During this process, an important realization emerged. Many persistence operations developers perform daily are not fundamentally ORM problems. They are application-level data access problems: creating, retrieving, updating, and deleting data; applying simple queries; projecting partial views; handling pagination; and managing transactional boundaries. These concerns exist regardless of whether the underlying database is relational.

That realization led directly to the creation of Jakarta Data.

Jakarta Data

Jakarta Data, released as version 1.0 on June 6th, 2024, introduces a repository-style API that standardizes data access across both relational and NoSQL databases. Rather than replacing Jakarta Persistence, it complements it by operating at a different abstraction level. Jakarta Persistence remains an ORM API, strongly tied to SQL semantics, JDBC data sources, and provider-specific behavior. Jakarta Data, by contrast, is largely store-agnostic and optimized for fast, application-level data access.

This difference in abstraction is essential to understanding why Jakarta Data exists. Jakarta Persistence addresses how an object is mapped and stored in a relational database. Jakarta Data answers a different question: how an application interacts with data, independent of how that data is physically stored.

At the core of Jakarta Data is the repository concept. A repository is defined as a mediator between an application’s domain logic and the underlying data storage, whether that storage is relational, NoSQL, or something else entirely. While this idea will feel familiar to developers who have used Spring Data or similar frameworks, Jakarta Data is careful not to enforce a single repository style.

Early approaches favored DAO-style repositories, with one repository per entity and method-name–based queries. This approach is easy to understand but can feel unnatural in real-world domains, where many operations span multiple entities. Jakarta Data, therefore, also supports non-generic repositories, allowing engineers to group operations in ways that reflect domain concerns rather than database structure. The emphasis is on type safety and intentional design, not on mechanical uniformity.

This layered approach becomes clearer when looking at the programming model.

With Jakarta NoSQL, developers work with familiar mapping annotations and a template-based API. For example:

@Entity
public class NoSQLEntity {

    @Id
    private String id;

    @Column
    private String name;
}

Using the Jakarta NoSQL template, interacting with the database is explicit and straightforward:

@Inject
Template template;

Optional<NoSQLEntity> entity =
        template.find(NoSQLEntity.class, "1");

NoSQLEntity newEntity =
        new NoSQLEntity("1", "test");

template.insert(newEntity);

Jakarta Data builds on top of this foundation by introducing repositories that express intent more directly. A simple repository example looks like this:

@Repository
public interface Library {

    @Insert
    void addToCollection(Book book);

    @Delete
    void removeFromCollection(Book book);
}

Within a Jakarta Data repository, developers can define default methods, lifecycle methods annotated with @Insert, @Update, @Delete, or @Save, derived query methods annotated with @Find, explicit query methods annotated with @Query, projections, pagination, and resource accessor methods. The goal is not to hide complexity, but to concentrate it within a consistent, well-defined abstraction.

Jakarta Data also introduces an important distinction in execution style. In Jakarta EE 11, repositories are stateless: changes must be explicitly persisted by calling a save method. Jakarta EE 12, currently in progress, will introduce managed, stateful repositories that automatically track and persist changes to entities. This allows teams to choose between explicit control and managed convenience based on architectural needs.

Jakarta Data did not appear in isolation. It builds on lessons learned from earlier efforts such as GORM, Spring Data, DeltaSpike Data, and Panache. What differentiates Jakarta Data is not novelty, but standardization. It provides a vendor-neutral model that integrates cleanly with the rest of the Jakarta EE platform.

Today, Eclipse JNoSQL 1.1.10 is the only implementation that spans NoSQL databases and supports Jakarta Data. Through its Jakarta Persistence driver, it can run on top of any JPA provider, such as Hibernate or EclipseLink. This enables the same repository abstraction to be applied across fundamentally different storage technologies.

Looking ahead, the next major step is Jakarta Query, a specification designed to align query languages across Jakarta Persistence, Jakarta Data, and Jakarta NoSQL. Together, these efforts mark what many describe as the beginning of the “Data Age” in Jakarta EE.

Jakarta Data is not “JPA 2.0,” and Jakarta NoSQL is not an ORM for non-relational databases. Instead, they represent a shift in perspective. Persistence in enterprise Java is no longer defined solely by how data is stored, but by how applications interact with data in a world where multiple storage paradigms coexist.

That shift has taken more than a decade — and Jakarta EE 11 is where it finally becomes visible.

References and Inspiration

• Arjan Tijms – Next-level persistence in Jakarta EE: Jakarta Data and Jakarta NoSQL:
  https://omnifish.ee/next-level-persistence-in-jakarta-ee-jakarta-data-and-jakarta-nosql-jfall-slides/
• Slides:
  https://drive.google.com/file/d/1qQH919SU4dcMFLclJrml4l-EhoB4V85x/view