DynamoDB PartiQL vs SQL: Was bricht

Die mit Abstand größte Quelle von Verwirrung bei DynamoDB PartiQL — für Menschen wie für KI-Assistenten — ist, es als relationales SQL zu behandeln. Ist es nicht. PartiQL ist eine SQL-kompatible Oberfläche über den bestehenden Operationen von DynamoDB, keine Abfrage-Engine, die joinen, gruppieren oder aggregieren kann. Die vertrauten Schlüsselwörter verbergen eine ganz andere Maschine darunter.

Wie unterscheidet sich DynamoDB PartiQL von SQL?

PartiQL leiht sich die Syntax von SQL, aber nicht dessen Engine. Auf DynamoDB bildet jedes Statement auf eine einzige native Operation ab — GetItem, Query, Scan, PutItem, UpdateItem oder DeleteItem — also gibt es keinen JOIN, kein GROUP BY, keine Subquery und kein Aggregat. Es liest sich wie SQL, kann aber nur das tun, was diese Key-Value-Operationen ohnehin tun.

Jedes PartiQL-Statement kompiliert zu einer der nativen Operationen von DynamoDB:

Du schreibst	DynamoDB führt aus
`SELECT … WHERE PK = …`	`GetItem` oder `Query`
`SELECT …` (ohne PK)	`Scan` (liest die ganze Tabelle)
`INSERT INTO …`	`PutItem`
`UPDATE … WHERE PK=… AND SK=…`	`UpdateItem` (ein Item)
`DELETE … WHERE PK=… AND SK=…`	`DeleteItem` (ein Item)

Es gibt keinen Planner, der aus zwei Tabellen lesen, einen Hash-Join bauen oder Zeilen zu einem COUNT zusammenfalten kann. Wenn eine Operation nicht auf ein einzelnes Get/Query/Scan/Put/Update/Delete abbildet, kann PartiQL sie schlicht nicht ausdrücken. Das ist die ganze Geschichte — alles Weitere unten ist eine Folge dieser einen Tatsache.

Dieselbe Abbildung als Ablauf — die WHERE-Klausel entscheidet, ob ein SELECT eine günstige Query oder ein Full-Table-Scan ist:

Jedes Statement löst sich zu genau einer nativen Operation auf — diese 1:1-Abbildung ist der Grund, warum PartiQL nicht joinen, gruppieren oder aggregieren kann.

Was anders ist — Feature für Feature

Überall dort, wo die Workbench-Spalte Ja gegen ein PartiQL Nein stellt, ist das eine Lücke, die DynoTables SQL schließt. Die Workbench materialisiert deine Tabellen durch die echte Query-Runtime von DynamoDB und führt darüber echtes SQL aus — SQL innerhalb der Zugriffsmuster-Regeln von DynamoDB.

Feature	Standard-SQL	DynamoDB PartiQL	DynoTable Workbench
`JOIN … ON …`	Ja	Nein	Ja — `INNER` / `LEFT` (auf einen PK oder GSI-Partition-Key)
`RIGHT` / `FULL` / `CROSS` / Komma-Join	Ja	Nein	Nein
Self-Join	Ja	Nein	Nein (noch nicht)
Subqueries / abgeleitete Tabellen	Ja	Nein	Nein
CTEs (`WITH …`)	Ja	Nein	Nein
`UNION` / `INTERSECT` / `EXCEPT`	Ja	Nein	Nein
`GROUP BY` / `HAVING`	Ja	Nein	Ja
Aggregate (`COUNT`/`SUM`/`AVG`/`MIN`/`MAX`)	Ja	Nein	Ja
`DISTINCT`	Ja	Nein	Ja
`CASE` / `CAST`	Ja	Nein	Ja
Window-Funktionen	Ja	Nein	Nein
`ORDER BY`	Ja, jede Spalte	Teilweise — nur Sort-Key (braucht Partition-Key-`WHERE`)	Ja, jede Spalte
`LIMIT`	Ja	Nicht inline (nutze den Request-Parameter `limit`)	Ja
`LIKE`	Ja	Nein (nutze `contains` / `begins_with`)	Ja
`IS NULL` / `IS NOT NULL`	Ja	Ja (fehlende Attribute sind `MISSING`, nicht `NULL` — nutze `IS MISSING`)	Ja
`SELECT *` ohne PK	scannt	Teilweise — stiller Full-Table-`Scan`	Ja (mit Kostentransparenz)

Was bricht, und warum

Das sind die Fehler, die DynoTables PartiQL-Validator markiert, bevor die Abfrage je die Leitung erreicht — jeder lässt sich auf eine echte DynamoDB-Einschränkung zurückführen.

SELECT * ohne ist ein versteckter Scan. PartiQL wirft keinen Fehler; es liest einfach jedes Item und filtert danach, was die klassische Query-vs-Scan-Kostenfußangel hinter freundlicher Syntax ist.
UPDATE / DELETE brauchen den vollständigen Primary Key. Sie bilden auf ein Einzelitem-UpdateItem/DeleteItem ab, also muss das WHERE den Partition Key festnageln (und den Sort-Key, auf einer -Tabelle). Du kannst nicht „alle Zeilen mit status = 'open' aktualisieren“ in einem Statement.
Doppelte Anführungszeichen sind Bezeichner, keine Strings. DynamoDB PartiQL folgt hier dem SQL-Standard: "name" ist ein Spalten-/Tabellenname, 'name' ist ein String-Wert. Einen Wert mit doppelten Anführungszeichen zu quoten ist der häufigste Anfängerfehler — die Meldung des Validators lautet wörtlich „Double quotes delimit identifiers in DynamoDB PartiQL, not strings. Use single quotes for string values.“
IN nutzt eckige Klammern, keine runden: WHERE pk IN ['a','b'], gedeckelt auf 50 PK-Werte / 100 Nicht-Schlüssel-Werte.
Kein JOIN, keine Aggregate. Es gibt keine Engine, um Tabellen zu kombinieren oder Zeilen zusammenzufalten. Das ist der Single-Table-Design-Trade-off: Du modellierst vorab für deine Zugriffsmuster, weil die Query-Schicht die Daten nachträglich nicht umformen kann.

Warum KI-Assistenten das falsch machen

LLMs werden auf Ozeanen von relationalem SQL trainiert, also emittieren sie selbstbewusst JOIN, GROUP BY, LIKE, inline LIMIT und doppelt gequotete String-Literale gegen DynamoDB — die DynamoDB allesamt ablehnt. DynoTables eigener Modell-Query-Autofix existiert genau deshalb, weil billige Modelle diese Muster zuverlässig erzeugen: Er entfernt doppelt-escapte Anführungszeichen, schreibt LIKE '%x%' → contains um, IS NULL → attribute_not_exists und hebt inline LIMIT auf den Request-Parameter. Wenn deine KI „PartiQL“ generiert, das sich wie Postgres liest, ist das das Warnsignal.

Jede Karte zeigt das SQL, zu dem eine relationale Entwicklerin greift, was DynamoDB PartiQL tatsächlich damit macht, und warum. Karten mit der Markierung „Läuft in DynoTable“ zeigen das äquivalente SQL, das die Workbench ausführen kann.

Joining two tables

Nicht in PartiQL

SELECT o.id, c.name
FROM orders o
JOIN customers c ON o.customerId = c.PK

GROUP BY and aggregates

Nicht in PartiQL

SELECT country, COUNT(*) AS orders, SUM(total) AS revenue
FROM orders
GROUP BY country

Subqueries

Nicht in PartiQL

SELECT * FROM orders
WHERE customerId IN (SELECT PK FROM customers WHERE country = 'ES')

UNION across tables

Nicht in PartiQL

SELECT PK FROM orders
UNION
SELECT PK FROM archived_orders

SELECT * (the hidden Scan)

Funktioniert, mit Einschränkungen

SELECT * FROM orders

Updating many rows by a filter

Nicht in PartiQL

UPDATE orders SET status = 'shipped'
WHERE status = 'open'

Quoting string values

Funktioniert, mit Einschränkungen

SELECT * FROM users WHERE "name" = "Alice"

DynoTables SQL Workbench: die Abfragen, die PartiQL nicht ausführen kann

Wenn du wirklich einen JOIN oder ein GROUP BY brauchst, ist DynoTables SQL Workbench die Antwort. Sie validiert die To-Seite jedes JOIN gegen einen Partition Key, materialisiert die gejointen Zeilen durch die echte Query-/Scan-Runtime von DynamoDB und führt dann ein einzelnes SELECT (Aggregate, GROUP BY, DISTINCT, CASE, CAST) darüber aus — SQL innerhalb der Zugriffsmuster-Regeln von DynamoDB.

-- Runs in the DynoTable Workbench (NOT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

Ehrliche Einschränkungen (die Workbench erzwingt das Zugriffsmodell von DynamoDB, sie gibt nicht vor, Postgres zu sein):

Nur INNER JOIN und LEFT JOIN — das ON-To-Attribut muss ein Partition Key oder GSI-Partition-Key sein. Kein RIGHT / FULL / CROSS / Komma-Join.
Noch keine Self-Joins, keine Subqueries, keine abgeleiteten Tabellen, keine Window-Funktionen.
Joins und Projektionen arbeiten auf skalaren Attributen.

Wenn du nur Bedingungen und Schlüsselausdrücke für die rohe API zusammenstellen musst, generiert der DynamoDB Expression Builder die korrekte FilterExpression / KeyConditionExpression ganz ohne die PartiQL-Oberfläche. Für richtig gemachtes PartiQL siehe die durchgespielten PartiQL-Beispiele; um abzuschätzen, was eine Abfrage kosten wird, nutze den Item-Größenrechner. Beachte, dass PartiQL das Wire-Format nie ändert — Werte reisen weiterhin als DynamoDB-JSON. Du wählst einen Client? Sieh, wo die Workbench gegen eine einfache DynamoDB-GUI oder Dynobase steht.

FAQ

Ist PartiQL dasselbe wie SQL? Nein. PartiQL ist eine SQL-kompatible Abfragesprache, aber auf DynamoDB legt sie nur Operationen offen, die auf ein einzelnes Get/Query/Scan/Put/Update/Delete abbilden. Sie hat keine Joins, Aggregate, Subqueries oder GROUP BY.

Kann DynamoDB PartiQL einen JOIN? Nein. DynamoDB PartiQL kann keine Tabellen joinen. DynoTables SQL Workbench kann INNER/LEFT JOIN (auf einen Partition Key oder GSI-Partition-Key) ausführen, indem sie die Daten durch die echte Query-Runtime von DynamoDB materialisiert.

Unterstützt DynamoDB PartiQL GROUP BY oder COUNT? Nein — es gibt in DynamoDB PartiQL keine Aggregate oder GROUP BY. Nutze DynoTables SQL Workbench für COUNT/SUM/AVG/GROUP BY/HAVING-Abfragen.

Warum kostet mein SELECT * so viel? Ohne Partition Key im WHERE führt PartiQL einen Full-Table-Scan aus und misst jedes gelesene Item, bevor der Filter greift. Füge ein Partition-Key-Prädikat hinzu, um daraus eine Query zu machen.

Sollte ich in PartiQL einfache oder doppelte Anführungszeichen verwenden? Einfache Anführungszeichen für String-Werte ('CUSTOMER#42'), doppelte Anführungszeichen für Bezeichner wie Tabellen- und Attributnamen ("AppData"). Einen Wert doppelt zu quoten ist der häufigste PartiQL-Fehler.

Bereit, echtes SQL gegen DynamoDB auszuführen? Lade DynoTable herunter und öffne einen Workbench-Tab.