Ist DynamoDB schemalos?

Ja. DynamoDB ist schemalos. Außer dem Primärschlüssel definierst du beim Anlegen einer Tabelle keine Attribute und keine Datentypen. Jedes Item kann seinen eigenen, eigenständigen Satz an Attributen tragen, und die dürfen von Item zu Item frei variieren — du passt dein Datenmodell also an, ohne Schema-Migrationen auszuführen.

Was du vorab festlegst

Nur den Primärschlüssel: einen Partition Key (Pflicht) und einen optionalen Sort Key, dazu ihre Typen. Alles andere ist beliebig. Spalten deklarierst du nicht.

Was pro Item variiert

Zwei beliebige Items in derselben Tabelle können völlig unterschiedliche Attribute haben. Ein Item trägt vielleicht email und status, ein anderes orderTotal und eine verschachtelte address-Map. DynamoDB speichert, was du schreibst.

Wo schemalos endet

Schemalos hat eine präzise Grenze. Der Primärschlüssel wird bei jedem Write validiert, sonst nichts. Zwei Items ohne ein einziges gemeinsames Attribut landen klaglos in derselben Tabelle:

await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {pk: {S: 'USER#1'}, email: {S: 'a@b.c'}, status: {S: 'active'}}
  })
);
await client.send(
  new PutItemCommand({
    TableName: 'people',
    Item: {
      pk: {S: 'ORDER#1'},
      orderTotal: {N: '42.5'},
      address: {M: {city: {S: 'Madrid'}}},
      tags: {SS: ['a', 'b']}
    }
  })
);

Beide gelingen. Schreib jetzt denselben Partition Key als Zahl statt als String:

ValidationException: One or more parameter values were invalid: Type mismatch for key
HTTP 400

Und lass pk ganz weg:

ValidationException: One of the required keys was not given a value
HTTP 400

Diese zwei Zurückweisungen sind das gesamte Schema. Das Key-Attribut muss vorhanden sein und zu dem in AttributeDefinitions deklarierten Typ passen. Alles darüber hinaus wird so akzeptiert, wie es geschrieben wurde.

Ein Tippfehler kommt ebenfalls durch. Nichts sagt dir zur Schreibzeit, dass staus eigentlich status heißen sollte.

Warum das hilft

Keine Migrationen — Attribute jederzeit hinzufügen oder weglassen.
Gemischte Entitäten — viele Entitätstypen können sich eine Tabelle teilen (Single-Table-Design).
Weiterentwickelbar — das Modell ändert sich mit den Anforderungen.

Deine Anwendung erzwingt jede Form, auf die du dich verlässt, nicht die Datenbank.

Was schemalos nicht lockert

Schemalos gilt nur für Nicht-Schlüssel-Attribute. Jedes andere DynamoDB-Limit bleibt:

400 KB pro Item — Attributnamen und -werte zählen beide zur Obergrenze.
32 Verschachtelungsebenen für Maps und Listen innerhalb eines Werts.
65.535 Bytes maximale Länge für einen einzelnen Attributnamen.
25 Items maximal pro BatchWriteItem-Aufruf.

Du kannst einem Item einen status-String geben und ihn beim nächsten weglassen, aber du kannst in keinem von beiden einen 500-KB-Blob speichern. Nutze den Item-Size-Rechner, um eine Payload vor dem Schreiben zu messen, und lies Single-Table-Design, wenn du Entitätstypen in einer Tabelle mischst.

In DynoTable: öffne Einstellungen auf jeder Tabelle und indexiere sie. Das abgeleitete Schema entsteht aus gesampelten Items und ist ehrlich gelabelt — es zeigt, was du geschrieben hast, nicht was du deklariert hast. Siehe Tabellenübersicht und -indexierung dazu, wie der lokale Index sampelt und aktualisiert.

Tiefer einsteigen

Siehe Single-Table-Design und das Muster Type-Attribut für gemischte Items. Lade DynoTable herunter, um echte Item-Formen zu inspizieren.

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 auf Node v24.18.0 reproduziert. Beide ValidationException-Meldungen sind wortgetreue Engine-Ausgabe.