DynamoDB PartiQL vs. SQL: Was anders ist (und was kaputtgeht)

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

Das mentale Modell

Jede PartiQL-Anweisung wird auf eine von DynamoDBs nativen Operationen herunterkompiliert:

Es gibt keinen Planer, 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 Zuordnung als Fluss — die WHERE-Klausel entscheidet, ob ein SELECT ein günstiges Query oder ein Scan über die ganze Tabelle ist:

Jede Anweisung löst sich in genau eine native Operation auf — diese Eins-zu-eins-Zuordnung ist der Grund, warum PartiQL nicht joinen, gruppieren oder aggregieren kann.

Was anders ist — Feature für Feature

Jedes , das DynoTables SQL Workbench doch ausführen kann, ist markiert. Die Workbench materialisiert deine Tabellen über DynamoDBs echte Query/Scan-Laufzeit und führt darüber echtes SQL aus — SQL innerhalb von DynamoDBs Zugriffsmuster-Regeln.

Was kaputtgeht — und warum

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

• SELECT * ohne Partition-Key ist ein versteckter Scan. PartiQL meldet keinen Fehler; es liest einfach jedes Item und filtert hinterher — der klassische Query-vs-Scan-Kostenfallstrick hinter freundlicher Syntax.
• UPDATE / DELETE brauchen den vollständigen Primärschlüssel. Sie bilden auf ein einzelnes UpdateItem/DeleteItem ab, also muss das WHERE den Partition-Key festlegen (und den Sort-Key, bei einer Tabelle mit zusammengesetztem Schlüssel). Du kannst nicht „alle Zeilen aktualisieren, bei denen status = 'open'" in einer Anweisung.
• 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'], begrenzt auf 50 PK-Werte / 100 Nicht-Schlüssel-Werte.
• Kein JOIN, keine Aggregate. Es gibt keine Engine, die Tabellen kombiniert oder Zeilen zusammenfaltet. Das ist der Single-Table-Design- Kompromiss: Du modellierst vorab für deine Zugriffsmuster, weil die Abfrageschicht Daten im Nachhinein nicht umformen kann.

Warum KI-Assistenten das falsch machen

LLMs werden auf Ozeanen relationalen SQLs trainiert, also geben sie selbstbewusst JOIN, GROUP BY, LIKE, inline LIMIT und doppelt-gequotete String-Literale gegen DynamoDB aus — was DynamoDB alles ablehnt. DynoTables eigene Autokorrektur für Modell-Abfragen existiert genau deshalb, weil günstige Modelle diese Muster zuverlässig produzieren: Sie entfernt doppelt-escapte Anführungszeichen, schreibt LIKE '%x%' → contains um, IS NULL → attribute_not_exists und hievt inline LIMIT auf den Anfrageparameter. Wenn deine KI „PartiQL" erzeugt, das sich wie Postgres liest, ist das das verräterische Zeichen.

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

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

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

SELECT PK FROM orders
UNION
SELECT PK FROM archived_orders

SELECT * FROM orders

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

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 über DynamoDBs echte Query/Scan-Laufzeit und führt dann darüber dein vollständiges SQL aus (Aggregate, GROUP BY, DISTINCT, CASE, CAST) — SQL innerhalb von DynamoDBs Zugriffsmuster-Regeln.

-- 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 DynamoDBs Zugriffsmodell, 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 Unterabfragen, keine abgeleiteten Tabellen, keine Fensterfunktionen.
• Joins und Projektionen arbeiten auf skalaren Attributen.

Wenn du nur Bedingungen und Schlüsselausdrücke für die rohe API zusammensetzen musst, generiert der DynamoDB Expression Builder die korrekte FilterExpression / KeyConditionExpression ganz ohne die PartiQL-Oberfläche. Für richtig gemachtes PartiQL siehe die durchgearbeiteten PartiQL-Beispiele; um abzuschätzen, was eine Abfrage kostet, nutze den Item-Größen-Rechner. Beachte, dass PartiQL nie das Wire-Format ändert — Werte reisen weiterhin als DynamoDB-JSON. Bei der Wahl eines Clients? Sieh, wo die Workbench gegen eine schlichte DynamoDB-GUI oder Dynobase landet.

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, Unterabfragen oder GROUP BY.

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

Unterstützt DynamoDB PartiQL GROUP BY oder COUNT? Nein — in DynamoDB PartiQL gibt es 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 Scan über die ganze Tabelle aus und misst jedes gelesene Item ab, bevor der Filter greift. Füge ein Partition-Key-Prädikat hinzu, um es in einen Query zu verwandeln.

Soll ich in PartiQL einfache oder doppelte Anführungszeichen nutzen? 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.