High Speed JPA

JPA, dem Jakarta Persistence API, wird immer wieder nachgesagt „zu langsam für die Praxis“ zu sein. Dennoch steckt sie seit Jahren in unzähligen Projekten – und sorgt dort unauffällig für stabile Unternehmensanwendungen. Sind die Vorwürfe bezüglich der Performance also nur Panikmache? Die Wahrheit liegt irgendwo dazwischen: JPA selbst ist nicht das Problem, aber die Art, wie wir es einsetzen, kann in ein Performance-Desaster führen.

In diesem Artikel schauen wir uns an, warum grüne Tests trügerisch sein können – und welche einfachen Tricks helfen, JPA von einem vermeintlichen Bremsklotz zu einem zuverlässigen Highspeed-Werkzeug zu machen.

Das JPA-Paradox

In der Testumgebung wirkt alles harmlos. Alle Unit-Tests sind grün, die Integrationstests laufen sauber durch, selbst auf dem Staging-System reagiert die Anwendung blitzschnell. Doch sobald das Produkt mit realen Daten online geht, ist es vorbei: Anfragen, die vorher in Millisekunden fertig waren, brauchen plötzlich Sekunden oder länger.

Viele Entwickler:innen kennen genau dieses Paradox. JPA will uns eigentlich Arbeit abnehmen: weniger SQL schreiben, weniger Boilerplate, mehr Fokus auf das Domänenmodell. Und meistens klappt das auch. Aber hinter der Bequemlichkeit verstecken sich Fallstricke. Defaults, die in kleinen Testdatenbanken unter dem Radar fliegen, können in Produktion die Performance komplett einbrechen lassen.

JPA ist nicht per se langsam. Langsam wird es durch Fehler bei der Verwendung. Das Gute daran: Wer die Muster einmal verstanden hat, kann sie vermeiden. Und dann läuft JPA auch im Betrieb unter Last rund.

Ein kurzer Blick zurück

Um zu verstehen, warum JPA so funktioniert, wie es funktioniert, lohnt sich ein kleiner Blick in die Geschichte des Object-Relational Mapping (ORM) in der Java-Welt.

In den 90ern hieß Datenbankzugriff: SQL von Hand schreiben, PreparedStatement-Objekte jonglieren und Ergebniszeilen manuell in Domänenobjekte umwandeln. Das war manchmal mächtig, aber meistens nervig – und in größeren Systemen extrem fehleranfällig und wartungsintensiv.

Anfang der 2000er lieferten Frameworks wie TopLink und Hibernate eine neue Idee: Statt SQL von Hand zu schreiben, beschreibt ein Meta-Modell, wie Klassen auf Tabellen abgebildet werden, und das Framework übernimmt den Rest. Weniger Boilerplate Code, weniger Fehlerquellen. 2004 wurde dieses Vorgehen mit der Java Persistence API (JPA) standardisiert, später kam mit Spring Data JPA noch ein Framework dazu, das den Einstieg fast schon trivial machte. Heute ist Hibernate die am weitesten verbreitete JPA-Implementierung.

Aber jede Abstraktion hat ihren Preis. Jeff Atwood hat ORM mal als das „Vietnam der Informatik“ bezeichnet – extrem hilfreich, aber brandgefährlich, wenn man es als Allheilmittel versteht (Link zum Blogpost). JPA spiegelt genau das wider: In 95% der Fälle funktioniert alles problemlos. Die restlichen 5% bereiten im schlimmsten Fall schlaflose Nächte.

Und genau da steigen wir ein: beim berüchtigten N+1-Problem, bei Lazy-Loading-Fallen und bei versteckten Kosten, die erst sichtbar werden, wenn die Datenmengen richtig groß werden.

Das N+1-Querys-Problem: Warum es eigentlich 1+N heißen müsste

Eine der bekanntesten Stolperfallen mit JPA ist das sogenannte N+1-Querys-Problem bei Abfragen. Genau genommen müsste man es eher 1+N nennen: ein SELECT für die eigentliche Abfrage – und dann, im schlimmsten Fall, eine zusätzliche Abfrage für jeden einzelnen Datensatz. Das Tückische: Mit ein paar Dutzend Zeilen im Testsystem läuft alles blitzschnell. Doch sobald die Datenmenge wächst, schlägt der Effekt gnadenlos zu.

Nehmen wir ein einfaches Beispiel aus unserem Demo-Projekt (Code auf GitLab): Wir haben Firmen und Mitarbeiter:innen, verknüpft über eine @ManyToOne-Relation in der Employee-Entität:

@Entity
@Table(name = "company")
public class Company {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name="id")
    private Long id;

    @Column(name = "name")
    private String name;

    @OneToMany(mappedBy = "company")
    private List<Office> offices;

    @OneToMany(mappedBy = "company")
    private List<Employee> employees;
}

@Entity
@Table(name = "employee")
public class Employee {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name="id")
    private Long id;

    @Column(name="first_name")
    private String firstname;

    @Column(name="last_name")
    private String lastname;

    @ManyToOne
    @JoinColumn(name = "company_id")
    private Company company;

    @Column(name = "age")
    private Integer age;
}

Für den Zugriff kommt ein ganz normales Spring-Data-Repository zum Einsatz:

@Repository
public interface EmployeeRepository extends JpaRepository<Employee, Long> {
 // … some custom query methods …
}

Der folgende Aufruf wirkt erstmal harmlos:

List<Employee> employees = employeeRepository.findAll();

Er sieht nach einer einzigen Abfrage aus – tatsächlich entstehen aber schon bei winzigen Datenmengen mehrere Abfragen:

select e1_0.id, e1_0.age, e1_0.company_id, e1_0.first_name, e1_0.last_name
from employee e1_0

select c1_0.id, c1_0.name from company c1_0 where c1_0.id=?

select c1_0.id, c1_0.name from company c1_0 where c1_0.id=?

select c1_0.id, c1_0.name from company c1_0 where c1_0.id=?

Der komplette Testfall zum Nachlesen: Link zum Test.

Eine Abfrage für die Mitarbeitenden – und dann eine pro Firmenreferenz. Mit zehn Mitarbeitenden sind das maximal elf Abfragen. Kein Drama. Aber bei 10.000 Mitarbeitenden in 500 Firmen plötzlich 501 Abfragen! Wenn jede Abfrage 10 ms dauert, verbrennt der Request schon mehr als fünf Sekunden. In Produktion ein Totalausfall.

Zum Glück bietet JPA mit dem Konzept des EntityGraphs einen einfachen Ausweg. Im Spring Data JPA Repository teilt die @EntityGraph Annotation der Persistence-Schicht mit, bestimmte Referenzen direkt mit zu laden:

@Repository
public interface EmployeeRepository extends JpaRepository<Employee, Long> {

    @EntityGraph(attributePaths = { "company" })
    List<Employee> readAllBy();

}

Das Ergebnis: statt unzähliger Einzelabfragen baut Hibernate ein einziges JOIN – genau so, wie wir es früher von Hand mit SQL gemacht hätten:

select e1_0.id, e1_0.age, c1_0.id, c1_0.name, e1_0.first_name, e1_0.last_name
from employee e1_0
left join company c1_0 on c1_0.id = e1_0.company_id

Egal wie groß die Datenmenge wird: Alle Daten gelangen durch eine einzige Datenbankabfrage in den JPA Kontext.

In einem Kundenprojekt stand uns genau dieses Problem im Weg: Ein simpler Synchronisationsjob brauchte in der Testumgebung nur ein paar Sekunden – in Produktion aber mehrere Stunden. Zum Glück war alles testgetrieben entwickelt. Wir konnten gezielt EntityGraphs einsetzen, ohne die Business-Logik anfassen zu müssen. Zwei Stunden Optimierungsarbeit, und die Laufzeit schrumpfte von mehreren Stunden auf etwa zehn Minuten – für den Anwendungsfall völlig akzeptabel.

Das N+1-Problem ist kein Fehler von JPA sondern liegt in der Anwendung des Frameworks. Sobald man das Muster erkannt hat, ist die Lösung simpel – aber dafür muss man über grüne Tests hinausdenken und die Realität der Produktionsdaten im Blick haben.

Lazy vs. Eager Loading: Die subtile Performance-Falle

Wenn das N+1-Problem der laute Warnschuss ist, dann sind Lazy- und Eager-Loading die stillen Komplizen. Das Konzept klingt erstmal simpel: Lazy lädt Daten nur bei Bedarf, Eager direkt beim ersten Zugriff. In der Praxis sind die Standardwerte von JPA aber oft überraschend – und manchmal unangenehm teuer.

Per Spezifikation gilt:

• @ManyToOne ist standardmäßig EAGER
• @OneToMany ist standardmäßig LAZY

Eine mit @ManyToOne annotierte eingebette Entity wird direkt nachgeladen, während die mit @OneToMany annotierte Collection erst bei Bedarf aus der Datenbank angefragt wird.

Klingt erstmal simpel – kann aber böse Folgen haben:

Long employeeCount = allCompanies.stream()
    .mapToLong(c -> (long) c.getEmployees().size())
    .sum();

Das Beispiel sieht nach harmloser Stream-Logik aus. Aber jeder Aufruf von c.getEmployees().size() kann im Hintergrund eine neue SQL-Abfrage auslösen. Bei drei Firmen kein Problem, aber mit Hunderten Firmen bläht sich das plötzlich zu Hunderten zusätzlicher Queries auf. Die Tatsache, dass der Aufruf und damit das Auslösen der Querys weit entfernt vom eigentlichen Datenzugriff passiert, erschwert die Analyse der Performanceprobleme zusätzlich.

select c1_0.id, c1_0.name from company c1_0

select e1_0.id, e1_0.company_id, e1_0.age, e1_0.first_name, e1_0.last_name from employee e1_0 where e1_0.company_id=?

select e1_0.id, e1_0.company_id, e1_0.age, e1_0.first_name, e1_0.last_name from employee e1_0 where e1_0.company_id=?

select e1_0.id, e1_0.company_id, e1_0.age, e1_0.first_name, e1_0.last_name from employee e1_0 where e1_0.company_id=?

...

Probleme durch Lazy-Loading vermeiden

Grundsätzlich machen zwei Wege Sinn, der Einsatz ist je nach spezifischer Projektsituation zu entscheiden.

Wenn nach dem Laden definitv auf die eingebette Collection zugegriffen wird, bietet sich der Join-Fetch mittels EntityGraph an. Die Umsetzung erfolgt wie für das N+1 Queries Problem. Aber Achtung: Wenn andere die Repository-Methode mitnutzen und die zusätzlichen Daten nicht verwenden, erzeugt das größere Result-Sets deutlich mehr Traffic im System.

Streams in Java verführen dazu, Berechnungen im Code zu machen, die die Datenbank viel effizienter durchführen könnte. Summenbildung oder die Berechnung eines Durchschnittswerts kann per JPQL Query effizient in der Datenbank erfolgen.

@Query(
    "select new de.mischok.academy.companydatabase.domain.CompanyAverageAge(e.company, avg(e.age))
    from Employee e group by e.company")
List<CompanyAverageAge> getAverageAges();

So kümmert sich die Datenbank um die Aggregation und das mit genau einer Abfrage. Das Collection-Loading entfällt dadurch komplett. Das Repository zeigt den vollständigen Test mit allen Hilfsklassen: JPQL-Test.

Die andere Seite der Medaille: Eager Loading

So anfällig Lazy-Loading bei unbedachter Anwendung erscheint – Eager ist mindestens genauso tückisch. Insbesondere bei zentralen Domänenobjekten zieht JPA bei Eager-Loading gerne die halbe Datenbank mit. Ein einzelnes Statement bläht sich dann schnell zu einem Join-Monster auf. Und wenn es Referenzzyklen im Schema gibt, eskaliert das noch schneller. Werden die mühsam abgefragten Daten dann in der Geschäftslogik nicht verwendet, geht unter Umständen viel Performance verloren.

Die folgenden Punkte helfen beim einem durchdachten Umgang mit Eager-Loading:

• @ManyToOne explizit auf LAZY setzen, auch wenn JPA standardmäßig EAGER wählt. Aber Vorsicht: Manche LazyInitializationExceptions bleiben in transaktionalen Tests verborgen und treten erst in Produktion auf.
• Eager nur da einsetzen, wo es wirklich Sinn ergibt und die Daten definitiv gebraucht werden.
• Explizite Kontrolle bevorzugen, z. B. über @EntityGraph oder maßgeschneiderte Queries, wenn die Performance kritisch ist.

Fazit: Weder Lazy noch Eager sind „böse“. Aber beide brauchen etwas Wachsamkeit. Sonst zieht eine unschuldige einzeilige Stream-Operation schnell einen Wasserfall von Querys nach sich, der die Performance komplett lahmlegt.

Shorts: Weitere Stolperfallen und Lösungen

Nicht jede JPA-Performance-Falle braucht ein ganzes Kapitel. Manche sind kleiner, aber nicht weniger gefährlich – und schleichen sich unbemerkt in die Anwendung. Drei Klassiker aus der Projekt-Praxis:

Zu viele Daten

Wenn Entitys, zum Beispiel durch einen REST Endpunkt, nach außen gereicht werden, entstehen schnell gigantische JSON-Payloads. Ein Company-Objekt mit eingebetteten Employees, die wiederum ihre Company referenzieren, und so weiter – im dümmsten Fall tritt bei der Serialisierung sogar ein Zirkelbezug auf.

Das Ergebnis: aufgeblähte Payloads, unnötige Serialisierung, hohe Netzwerklast. Und zudem noch das Risiko, sensible Felder versehentlich mit auszuliefern.

Lösung:

• REST-Responses bewusst designen, große Strukturen aufteilen.
• Pagination für große Collections einsetzen. Spring Data JPA bringt das von Haus aus mit, siehe in diesem Test: Link zur Testklasse.
• Mit DTOs (Data Transfer Objects) steuern, welche Felder wirklich nach außen dürfen.

Flushing

Im Transaktionskontext sammelt JPA Änderungen im Persistence Context. Irgendwann müssen diese Änderungen in die DB geschrieben werden – dieser Schritt ist jedoch teuer. Daher führt JPA den notwendigen flush() nicht ständig aus. Zum Teil erfordert die Business Logik jedoch das explizite Flushing.

Vorsicht ist vor allem in Schleifen geboten: Wenn flush() unbedacht in jedem Durchlauf aufgerufen wird, killt das unter Umständen die Performance. Jeder Flush zwingt JPA, alle Änderungen zu synchronisieren – und erzeugt oft mehr SQL Traffic, als man denkt.

Lösung:

• Standardmäßig dem Transaction Manager das Flushing überlassen.
• flush() nur dann einsetzen, wenn es wirklich gebraucht wird (z. B. Wenn mit gerade erzeugten IDs weitergearbeitet wird).
• Im Hinterkopf behalten: ein flush() nach der Schleife kann fachlich denselben Effekt haben wie ein flush() in jedem Schleifendurchlauf – aber mit dramatisch besserer Performance.

Speicherfallen

Entities sind keine simplen POJOs – auch wenn ihr Code das zunächst vermuten lässt. Sie tragen immer ihren Persistence State mit sich herum. Wer sie in HTTP-Sessions, Maps oder statischen Feldern parkt, fängt sich schnell unangenehme Memory-Leaks ein. Der Garbage Collector kann sie nicht freigeben, insbesondere auch nicht die von ihnen referenzierten Entitys. Die Folge: Der Heap läuft langsam aber sicher voll.

Lösung:

• Entities kurzlebig und stateless halten – nicht in Services oder Beans referenzieren.
• Wenn sie außerhalb des Persistence-Layer gebraucht werden: detach() auf dem EntityManager aufrufen.
• Keine Entities im Cache oder in Sessions speichern. IDs ablegen und bei Bedarf neu laden ist meist sicherer.

Jede dieser Fallen ist für sich genommen klein. In Summe können sie aber eine Anwendung zuverlässig ausbremsen. Wie beim N+1-Problem gilt: Wer die Muster kennt, kann sie einfach vermeiden.

Über JPA hinaus: Der ganzheitliche Blick

Bis hierhin haben wir uns konkrete Stolperfallen und ihre Lösungen angeschaut. Aber Performance hängt selten nur an einer Annotation oder einer speziellen Query. In der Praxis entsteht sie aus dem Zusammenspiel von Datenmodell, Zugriffsmustern und Architekturentscheidungen. JPA kann Teil eines hochperformanten Systems sein – aber nur, wenn man es richtig einsetzt.

1. Skalierung früh mitdenken

Viele JPA-Probleme bleiben bei kleinen Testdatenmengen unsichtbar. Eine Abfrage, die auf ein paar Dutzend Zeilen 5 ms braucht, kann auf Millionen Datensätzen plötzlich Sekunden dauern. Die einzige zuverlässige Methode, solche Probleme früh zu finden: Von Anfang an mit produktionsnahen Datenmengen testen. Teams, die realistische Testdaten in ihre CI-Pipelines integrieren, entdecken Engpässe lange bevor es die Nutzer merken.

2. JPA ist nicht immer das richtige Werkzeug

Für Standard-CRUD-Operationen ist JPA ein Produktivitätsbooster. Aber für komplexe Reports, große Aggregationen oder Massendatenjobs ist die Abstraktion unter Umständen eher Ballast. In solchen Fällen ist es oft sinnvoll, natives SQL zu schreiben oder Bibliotheken wie jOOQ einzusetzen. Verschiedene Ansätze zu mischen ist kein Makel – sondern ein Zeichen, dass Persistenz als ernsthafte Designfrage behandelt wird.

3. Performance ist nicht nur Technik

Optimierung ist sowohl ein technisches als auch ein organisatorisches Thema. Entwickler:innen brauchen die Freiheit, beim Datenzugriff den passenden Ansatz zu wählen. Teams brauchen die Disziplin, Standards zu hinterfragen. JPA zu optimieren bedeutet nicht, wahllos Annotationen zu setzen – sondern das Zusammenspiel von Code, Daten und Infrastruktur zu verstehen.

Kurz gesagt: JPA ist ein starkes Werkzeug, aber kein Allheilmittel. Erfolgreiche Teams setzen es dort ein, wo es glänzen kann – und greifen zu anderen Lösungen, wenn die Aufgabe es erfordert.

High Speed JPA ist möglich

Der Ruf, JPA sei langsam, ist definitiv nicht verdient. Wie wir gesehen haben, liegt es nicht am Framework selbst, wenn Anwendungen träge werden – sondern daran, wie wir es einsetzen. Das berüchtigte N+1-Problem, die Fallen von Lazy- und Eager-Loading, übermäßiges Flushing oder aufgeblähte REST-Payloads – all das sind keine Fehler von JPA, sondern Folgen von Defaults und Missverständnissen.

Die gute Nachricht: Die Lösungen sind meist einfach, sobald man sie kennt. @EntityGraph gezielt einsetzen. Lazy- und Eager-Defaults kritisch hinterfragen. Cascades vermeiden. Mit realistischen Daten testen. Mit diesen Prinzipien lassen sich die meisten Performance-Katastrophen gut antizipieren.

Die tiefere Erkenntnis ist aber: Persistenz darf kein Nebenschauplatz sein. Datenbankzugriff gehört genauso zur Architektur wie API-Design, Sicherheit oder User Experience. Mal ist die Lösung eine optimierte JPA-Query, mal eine DTO-Projection, mal schlicht ein nativer SQL-Call. Entscheidend ist, flexibel und pragmatisch zu bleiben – und die Trade-offs zu verstehen. Testgetriebene Entwicklung hilft zusätzlich, spätere Refactorings abzusichern.

Am Ende ist das Paradox, mit dem wir eingestiegen sind – grüne Tests in der Entwicklung, aber schlechte Performance in Produktion – keineswegs unvermeidbar. Mit den richtigen Tricks lassen sich die Produktivitätsvorteile von JPA nutzen, ohne in bekannte Fallen zu tappen.

High Speed JPA ist kein Wunschtraum. Es ist eine Frage von Bewusstsein, Design – und dem Mut, über die Defaults hinauszuschauen.