Kann DynamoDB Blobs speichern?

Ja, in Grenzen. DynamoDB speichert Binary Large Objects (BLOBs) in Binary-Attributen (B), auf der Leitung base64-kodiert, solange das gesamte Item unter 400 KB bleibt. Für alles Größere — Video, Audio, hochauflösende Bilder — empfiehlt AWS, den Blob in Amazon S3 abzulegen und in DynamoDB nur eine Referenz plus Metadaten zu halten.

Einen Blob direkt speichern

Leg die Bytes in ein Binary-Attribut. Anwendungen kodieren Binärwerte vor dem Senden nach base64; DynamoDB rechnet die rohe Byte-Länge auf die 400-KB-Item-Größe an. Kleine Blobs (Signaturen, kompakte Payloads) passen bequem hinein.

Wie viele Bytes tatsächlich hineinpassen

400 KB gelten für das Item, nicht für den Blob. Die Grenze per binärer Suche zu bestimmen ergibt eine exakte Obergrenze: Ein Item, das nichts als einen einstelligen Partition Key und ein Binary-Attribut enthält, fasst 409.594 Bytes Blob. Ein Byte mehr und der Write scheitert:

ValidationException: Item size has exceeded the maximum allowed size

Sechs realistische Metadaten-Attribute daneben (Content-Type, Abmessungen, Uploader, Zeitstempel) kosten 94 Bytes und drücken die Obergrenze auf 409.500.

Die base64-Kodierung ist ein Leitungsdetail und nicht mehr. Dieses 409.594-Byte-Put sendet 546.128 Bytes base64 im Request-Body, und DynamoDB akzeptiert es — die weit verbreitete Vorstellung, base64 fresse ein Drittel deines Budgets, ist also falsch. Was es sehr wohl kostet, ist Durchsatz: Ein Blob in voller Größe sind 400 Write-Einheiten pro Put und 100 Leseeinheiten pro stark konsistentem Read, gegenüber 1 und 0,5 für ein kleines Item.

Das Muster für große Objekte

Wenn ein Blob 400 KB überschreitet:

Leg das Objekt in Amazon S3 ab.
Halte den S3-Key plus Metadaten (Name, Größe, Eigentümer, Zeitstempel) in DynamoDB.

Das kombiniert DynamoDBs schnelle indizierte Lookups mit S3s günstigem, unbegrenztem Objektspeicher. Für Daten, die nur mäßig über der Grenze liegen, schlägt AWS außerdem vor, große Attribute zu komprimieren (GZIP- oder LZO-Ausgabe in einem Binary-Attribut abgelegt) oder sie über mehrere Items aufzuteilen.

Kompression rettet Text, nicht Medien

Dieser Kompressionsrat funktioniert bei genau einer Art Blob. gzip -9 über eine 614.499 Bytes große YAML-Lockfile ergibt 164.302 Bytes, ein Schnitt von 73 %, der sie von unmöglich auf bequem bringt. Derselbe Befehl über ein 794.311 Bytes großes PNG ergibt 785.175 Bytes, eine Ersparnis von 1,2 %, weil sich das Format bereits selbst komprimiert hat. Kompression verschafft dir also Platz für Logs, JSON-Payloads und Text — und gar nichts für die Mediendateien, die der übliche Grund sind, an die Grenze zu stoßen.

Ein Vorbehalt

Es gibt keine dienstübergreifenden Transaktionen zwischen DynamoDB und S3, deine Anwendung muss Teilfehler und verwaiste Objekte also selbst behandeln.

Tiefer einsteigen

Prüfe Größen mit dem Item-Size-Rechner und lies den Leitfaden zum Item-Size-Limit. Lade DynoTable herunter, um Binärdaten anzusehen.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

Am 2026-07-28 gegen DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 gemessen — beide Byte-Obergrenzen wurden per binärer Suche gefunden statt hergeleitet, und die gzip-Werte stammen aus dem Ausführen von gzip -9 auf den beiden beschriebenen Dateien. AWS' Produktions-Engine formuliert ihre Ablehnungen möglicherweise anders.