Das DynamoDB-Kostenmodell: Warum SQL die Rechnung verbergen kann

Echtes SQL gegen DynamoDB auszuführen ist mächtig — du bekommst JOINs, GROUP BY und beliebige WHERE-Klauseln über einer Datenbank, die von Haus aus keine davon bietet. Aber SQL wurde für eine Engine mit einem Query-Planner und Secondary Indexes auf jeder Spalte entworfen, und DynamoDB hat weder das eine noch das andere. Ein völlig legitimes SELECT kann zu einem Full-Table-Scan kompilieren, der jedes Item in der Tabelle liest — und dir in Rechnung stellt.

Das ist die zweischneidige Seite der SQL-Abstraktion: Sie lässt teure Zugriffsmuster kostenlos aussehen. Dieser Guide erklärt das darunterliegende Kostenmodell, damit der Komfort nie in einer überraschenden Rechnung endet, und zeigt, wie DynoTable die Kosten vor dem Ausführen der Query sichtbar macht.

Warum kostet SQL über DynamoDB mehr, als es aussieht?

Eine relationale Datenbank kann WHERE status = 'active' effizient beantworten, weil sie für jede Spalte, nach der du fragst, einen Index aufbaut. DynamoDB tut das nicht. Es antwortet effizient auf genau eine Sache: den Partition Key (optional eingegrenzt durch einen Sort Key oder einen Global Secondary Index). Alles andere ist ein Scan.

• Eine Gleichheit auf dem Partition Key ist eine Query. DynamoDB springt direkt zu den Items unter diesem Key und liest nur diese. Begrenzt und günstig.
• Alles andere ist ein Scan + Filter. DynamoDB liest jedes Item in der Tabelle und wendet dann dein WHERE als FilterExpression an — nach dem Lesen. Dir wird alles berechnet, was gescannt wurde, nicht die Handvoll zurückgegebener Zeilen.

Der letzte Punkt ist die Falle. Eine WHERE-Klausel sieht so aus, als würde sie die Arbeit eingrenzen. Auf einem Nicht-Key-Attribut grenzt sie nur die Ausgabe ein — die Lesekosten sind bereits ausgegeben.

Query vs. Scan: die RCU-Mathematik

DynamoDB rechnet Lesevorgänge in Read Capacity Units (RCU) ab:

• 1 RCU = ein stark konsistenter Lesevorgang eines Items bis 4 KB. Letztendlich konsistente Lesevorgänge kosten eine halbe Einheit. Lesevorgänge runden pro 4 KB auf.
• Eine Query liest nur die Items unter einem Partition Key — die Kosten skalieren mit den passenden Items, nicht mit der Tabelle.
• Ein Scan liest die gesamte Tabelle, 4 KB auf einmal. Eine 1-GB-Tabelle sind grob 262.000 letztendlich konsistente RCU für einen einzigen vollständigen Durchlauf — bei jedem Durchlauf, jedes Mal.

Eine FilterExpression reduziert diese Zahl nicht. Das Filtern geschieht nach dem Lesen, sodass ein gefilterter Scan genauso viel kostet wie ein ungefilterter. Rechne die echten Zahlen für deine Daten mit dem Item-Größenrechner und dem Preisrechner aus.

Welche SQL-Konstrukte werden still und leise zu Scans?

• WHERE ohne Gleichheit auf dem Partition Key → ein vollständiger Scan mit einem Filter nach dem Lesen.
• JOIN → es gibt keinen serverseitigen Join in DynamoDB. Jede gejointe Tabelle wird separat abgerufen und client-seitig zusammengefügt — ein N+1-Zugriffsmuster, eine Anfrage pro gejointer Zeile.
• COUNT, SUM, GROUP BY, Aggregate → es existiert keine serverseitige Aggregation, daher wird jedes passende Item gelesen. Über einen Scan bedeutet das, die gesamte Tabelle zu lesen.
• ORDER BY oder DISTINCT auf einem Nicht-Key-Attribut → Sortierung und Deduplizierung geschehen client-seitig über allem, was gescannt wurde.

Keines davon ist falsch auszuführen — manchmal ist ein Scan genau das, was du willst. Der Punkt ist, zu wissen, wann du einen ausführst.

Wie halte ich SQL ehrlich in Bezug auf Kosten?

• Entwirf Schlüssel rund um deine Zugriffsmuster. Die günstigste Query ist die, die dein Key-Schema bereits beantwortet. Plane es mit dem Single-Table-Design-Tool und dem Query-vs-Scan-Guide.
• Setze eine Gleichheit auf dem Partition Key in das WHERE, um eine Query statt eines Scans zu bekommen.
• Füge einen GSI hinzu für ein zweites Zugriffsmuster, statt zu scannen und zu filtern.
• Lies die Kosten, bevor du ausführst. DynoTables Workbench kompiliert dein SQL zur tatsächlichen DynamoDB-Operation und zeigt den Plan — Scan vs. Query, welchen Index sie nutzt, die Key-Bedingung vs. den Filter nach dem Scan und geschätzte RCU-Kosten — und markiert dann Full Scans und N+1-Joins inline. Es ist das EXPLAIN, das DynamoDB nie ausgeliefert hat. Siehe auch warum Scans langsam und teuer sind und On-Demand vs. Provisioned Capacity.

Verschärft DynoTables SQL das Kostenproblem?

Nein — denn es macht die Kosten sichtbar. Die Kritik an SQL-über-DynamoDB ist berechtigt: Eine Abstraktion, die Scans verbirgt, lässt dich dir selbst ins Knie schießen. DynoTables Antwort ist nicht, das SQL zu entfernen, sondern ein Kosten-Röntgenbild dahinterzusetzen. Jede Query im Workbench zeigt ihre echte DynamoDB-Form in der Vorschau, bevor sie ausgeführt wird, sodass du die Ergonomie von SQL und die Ehrlichkeit über RCUs und Schlüsseldesign behältst, die dir das native Modell gibt.

Brauche ich den KI-Agenten für all das?

Nein — der Tabellen-Viewer, das SQL Workbench und die Kostenvorschau funktionieren alle vollständig ohne ihn. Der KI-Agent ist eines der Aushängeschilder von DynoTable — ein DynamoDB-nativer Coding-Agent, der schema-bewusste Queries schreibt, Daten transformiert und mehr — und er ist da, wann immer du ihn willst. Er läuft auf deinem eigenen AWS Bedrock, sodass du direkt an AWS zu Selbstkosten zahlst (kein Aufschlag), und deine Daten verlassen nie dein Konto. Schalte ihn ein, wenn er hilft; der Kern-Client ist so oder so vollständig.

Ist meine Arbeit portabel?

Ja. DynoTable spricht Standards, keinen Walled Garden: Standard-SQL, Standard-AWS-Anmeldedaten und -SSO, CSV/JSON-Export, Schema-Export (abgeleitet) nach TypeScript, JSON-Schema oder Zod und einen MCP-Server, damit deine eigenen Tools und Agenten sich verbinden können. Deine Queries, Konfigurationen und Schemas exportieren sauber — nichts ist eingeschlossen.

Probier es aus

Lade DynoTable herunter und öffne das SQL Workbench gegen deine eigene Tabelle — die Kostenvorschau zeigt dir, was jede Query wirklich kostet, bevor du sie ausführst.