Wenn ein ORM das falsche Werkzeug ist

Ein ORM ist die richtige Standardwahl für CRUD – und das falsche Werkzeug in dem Moment, in dem eine Abfrage aufhört, wie Objektzugriff auszusehen, und beginnt, wie ein Report auszusehen.

Sie kennen den Moment vermutlich: Ein List-Endpoint, der im Staging noch problemlos lief, braucht in Produktion vier Sekunden, und das Query-Log ist voll mit nahezu identischen SELECTs, die niemand von Hand geschrieben hat. Window Functions, CTEs, Aggregationen über mehrere Joins und herstellerspezifische Operatoren sind genau die Stellen, an denen das vom ORM generierte SQL ineffizient oder schlicht unmöglich wird – und an denen der Wechsel zu Raw SQL sich auszahlt. Dieser Artikel zieht die Grenze präzise: wo Object-Relational Mapping die korrekte Standardwahl ist, wo es unbemerkt zum Flaschenhals wird und wie Sie daran vorbeigreifen, ohne die Sicherheit gegen Injection aufzugeben.

Raw SQL, Query Builder, ORMs: ein Abstraktionsspektrum

„ORM vs. Raw SQL” war nie eine binäre Entscheidung. Datenzugriff ist ein Spektrum von voller Kontrolle bis zu vollem Komfort – mit einer mittleren Ebene, die die meisten Vergleiche überspringen. Am einen Ende gibt Ihnen Raw SQL die native Sprache der Datenbank ohne Übersetzungsschicht. Am anderen bilden ORMs wie Djangos ORM, ActiveRecord, Hibernate, Prisma, Sequelize und SQLAlchemy Zeilen auf Objekte ab und generieren das SQL für Sie. Dazwischen liegen Query Builder.

Ein Query Builder formalisiert Abfragemuster als verkettbare Methoden und bleibt dabei nah am SQL, das er ausgibt. Die meisten ORMs bieten zusätzlich eine Möglichkeit, der Datenbank einen rohen String zu übergeben – dabei entfällt das Escaping, das ihre regulären Query-Methoden für Sie übernehmen, und die Tür zu SQL Injection steht wieder offen. Ein Builder ist ein anderes Werkzeug: Er komponiert SQL programmatisch, ohne vorzugeben, Objektzugriff zu sein. Knex ist ein aktiv gepflegter JavaScript-Query-Builder, laut Changelog seit Juni 2026 auf der 3.3.0-Linie; auf der JVM ist jOOQ eine typsichere SQL-DSL, aktuell auf der 3.21-Linie, deren Open Source Edition auf JDK 21 abzielt. Keines von beiden ist ein ORM, und beide erhalten die Parametrisierung – genau darum geht es. Wenn die ORM-Abstraktion gegen Sie arbeitet, ist die Builder-Ebene oft der richtige Zwischenschritt, bevor Sie zu handgeschriebenem SQL greifen.

Wann ist ein ORM das falsche Werkzeug?

Das Signal zum Wechsel ist kein Bauchgefühl, sondern konkret. Greifen Sie am ORM vorbei, wenn Sie auf eines dieser fünf Muster stoßen:

1. Analytische und report-artige Abfragen. Window Functions, rekursive CTEs, GROUP BY ... HAVING-Rollups und Reports über mehrere Joins sind die Stellen, an denen generiertes SQL ineffizient oder gar nicht ausdrückbar wird. Ein ORM optimiert für Objektzugriff, nicht für OLAP-artige Ausgaben.
2. Hot Paths und Bulk-Operationen. Auf einem stark frequentierten Endpoint oder bei einem Batch-UPDATE/INSERT summieren sich save()-Aufrufe pro Zeile und zusätzliche Round-Trips. Ein einziges mengenbasiertes Statement ersetzt Hunderte von ORM-Schreibvorgängen.
3. Die N+1-Falle. Weiter unten im Detail behandelt: das mit Abstand häufigste Performance-Problem bei ORMs.
4. Datenbankspezifische Features. Postgres-JSONB-Operatoren wie @> und ->>, Volltextsuche mit tsvector/tsquery, LATERAL-Joins und PostGIS-Geofunktionen sind Features, die viele ORMs nicht vollständig oder nicht idiomatisch abbilden können. Manche ORMs bieten Helfer (Djangos contrib.postgres), aber die Abdeckung bleibt lückenhaft.
5. Undurchsichtiges, „magisches” Verhalten. Wenn Sie das vom ORM erzeugte SQL weder sehen noch beeinflussen können, werden Debugging und Performance-Arbeit zum Ratespiel. Das ist der objektrelationale Impedance Mismatch, der als realer Kostenfaktor sichtbar wird – und er hat eine Sicherheitsdimension: Die Raw-Query-Methoden, die die meisten ORMs bereitstellen, liegen außerhalb ihres eigenen Escapings; wer dort einen Wert interpoliert, macht sich angreifbar.

Das N+1-Problem: benannt und behoben

Das N+1-Problem ist der häufigste Weg, auf dem ein ORM unbemerkt zum falschen Werkzeug wird: Lazy Loading feuert eine Abfrage pro Zeile ab, sodass aus einer Liste mit 100 Einträgen stillschweigend 101 Round-Trips werden. Die Schleife sieht harmlos aus:

# One query for authors, then one MORE per author for their books
for author in Author.objects.all():
    print(author.name, author.books.count())

Die Lösung ist Eager Loading, nicht Raw SQL. Djangos select_related und prefetch_related fassen diese Round-Trips zu einem JOIN oder einer einzelnen IN-Abfrage zusammen:

# Two queries total, regardless of author count
authors = Author.objects.prefetch_related("books")

Beheben Sie N+1 zuerst mit Eager Loading und greifen Sie erst dann zu Raw SQL, wenn selbst die eager geladene Form nicht passt – etwa wenn Sie ein Fenster-Aggregat pro Autor benötigen, das das ORM als weiteren Round-Trip ausdrücken würde. Ineffiziente ORM-Abfragen kündigen sich selten im Code an; sie zeigen sich als langsame API-Antworten und langsame Seitenladezeiten. Ein Session-Replay-Tool wie OpenReplay zeigt den langsamen Netzwerk-Request in der Session-Timeline und weist Sie auf den Endpoint hin, dessen Backend-Abfrage Aufmerksamkeit braucht – also auf den Ort des Symptoms, nicht auf die Abfrage selbst. Zum tieferliegenden Trade-off siehe OpenReplays Leitfaden zur Vermeidung von SQL Injection.

Worauf verzichten Sie, wenn Sie Raw SQL schreiben?

Wenn Sie Raw SQL schreiben, erben Sie die eine Aufgabe, die das ORM still für Sie erledigt hat: Injection-Sicherheit. Übergeben Sie Benutzereingaben immer über Parameter-Platzhalter und verketten Sie sie niemals in den Query-String. Djangos Leitfaden zu Raw-SQL-Abfragen beschreibt die Mechanik: cursor.execute() nimmt %s-Platzhalter plus eine separate Werteliste entgegen, und der Treiber escapt jeden Wert beim Einsetzen, sodass er nie Teil des Statement-Texts wird.

# Safe: %s is the psycopg/DB-API placeholder, not string formatting
from django.db import connection
with connection.cursor() as cursor:
    cursor.execute("SELECT * FROM book WHERE author = %s", [user_input])
    rows = cursor.fetchall()

Lassen Sie die Platzhalter unquotiert: %s im SQL-String in Anführungszeichen zu setzen, wirft diesen Schutz weg. Rusts SQLx übernimmt den Platzhalter von der Datenbank – also $1 in Postgres, aber ? in MySQL, MariaDB und SQLite. Über Injection hinaus nehmen Sie außerdem mehr Boilerplate, eine engere Bindung an einen SQL-Dialekt und das manuelle Mapping von Ergebniszeilen zurück auf Objekte in Kauf.

Sie müssen das Sicherheitsnetz nicht aufgeben, um das ORM aufzugeben. Werkzeuge mit Compile-Time-Prüfung erhalten es: SQLx (0.9) verifiziert Abfragen vor dem Programmstart gegen das Schema, und die eigene Dokumentation stellt klar, dass es kein ORM ist; jOOQ (3.21) leistet dasselbe auf der JVM. Query Builder liegen dazwischen. „ORM vs. Raw SQL” ist eine falsche Dichotomie: Die eigentliche Achse ist, wie viel Abstraktion jede einzelne Abfrage verdient.

Das pragmatische Fazit zu ORM vs. Raw SQL

Nutzen Sie das ORM für die ~80 % einfachen CRUD-Fälle und wechseln Sie über dessen eigenen Escape Hatch zu Raw SQL – für genau die Abfragen, die es rechtfertigen. Das ORM zu verlassen bedeutet nicht, es zu entfernen. Django dokumentiert drei Wege: RawSQL, um ein parametrisiertes Fragment in eine ORM-Abfrage einzusetzen, Manager.raw() für eine Raw-Abfrage, die weiterhin Modellinstanzen zurückgibt, und connection.cursor(), um die Modellschicht ganz zu umgehen. SQLAlchemy stellt text() bereit; Prisma liefert TypedSQL, derzeit ein Preview-Feature, sowie $queryRaw für untypisierten Zugriff.

Die Entscheidung lässt sich auf eine kurze Tabelle reduzieren:

Raw SQL ist kein Rewrite, sondern ein gezielter Escape Hatch für die Handvoll Abfragen, bei denen das generierte SQL der Flaschenhals ist. Behalten Sie das ORM als Standard, profilen Sie den langsamen Endpoint und setzen Sie handgeschriebenes, parametrisiertes SQL genau dort ein, wo der Query-Plan belegt, dass es angebracht ist – und nirgendwo sonst.

FAQs

Ist Raw SQL tatsächlich schneller als ein ORM?

Nicht per se. Eine gut geschriebene ORM-Abfrage und eine gut geschriebene Raw-Abfrage treffen auf denselben Query Planner, Raw SQL ist also nicht automatisch schneller. Raw SQL gewinnt konkret dann, wenn die vom ORM generierte Abfrage der Flaschenhals ist – zusätzliche Round-Trips, N+1-Muster, breite unbegrenzte SELECTs oder Hot Paths, auf denen mengenbasierte Statements zeilenweise Schreibvorgänge ersetzen. Der Geschwindigkeitsvorteil entsteht daraus, schlechtes generiertes SQL zu beheben, nicht aus Raw SQL selbst.

Was ist der Unterschied zwischen einem Query Builder und einem ORM?

Ein Query Builder komponiert SQL programmatisch über verkettbare Methoden und bleibt dabei nah am ausgegebenen SQL; er bildet Zeilen nicht auf Objekte ab. Ein ORM bildet Datenbankzeilen auf Objekte der Programmiersprache ab und verbirgt das SQL vollständig. Knex ist ein Query Builder für JavaScript und jOOQ eine typsichere SQL-DSL für die JVM – keines von beiden ist ein ORM. Beide erhalten die Parametrisierung, sodass Sie die Objekt-Mapping-Abstraktion aufgeben, ohne die Injection-Sicherheit zu verlieren.

Wie schreibe ich Raw SQL, ohne meine Anwendung SQL Injection auszusetzen?

Übergeben Sie jeden vom Benutzer gelieferten Wert über Parameter-Platzhalter und verketten Sie Eingaben niemals in den Query-String. In Django mit psycopg ist der Platzhalter %s, und der Datenbanktreiber escapt die Parameter automatisch; Rusts SQLx übernimmt den Platzhalter von der Datenbank, also $1 in PostgreSQL, aber ? in MySQL, MariaDB und SQLite. Setzen Sie die Platzhalter im SQL-String nicht in Anführungszeichen. Werkzeuge mit Compile-Time-Prüfung wie SQLx verifizieren Abfragen vor dem Programmstart gegen das Schema und fügen damit eine weitere Sicherheitsebene hinzu.

Kann ich Raw SQL innerhalb eines ORM nutzen, ohne das ORM zu entfernen?

Ja. Jedes große ORM bietet einen Escape Hatch, mit dem Sie Raw SQL ausführen und das ORM dennoch als Standard beibehalten können. Django bietet connection.cursor() für die direkte Ausführung, Manager.raw(), um Modellinstanzen zurückzugeben, und RawSQL für parametrisierte Fragmente innerhalb von ORM-Abfragen; SQLAlchemy stellt text() bereit; Prisma liefert TypedSQL als Preview-Feature sowie $queryRaw für untypisierten Zugriff. Nutzen Sie das ORM für Standard-CRUD und greifen Sie nur für die konkreten Abfragen zu Raw SQL, bei denen das generierte SQL der Flaschenhals ist.