DynamoDB è schemaless?

Sì. DynamoDB è schemaless. A parte la chiave primaria, non definisci alcun attributo o tipo di dato quando crei una tabella. Ogni item può portare il proprio insieme distinto di attributi, e possono variare liberamente da un item al successivo — così adatti il tuo modello dati senza eseguire migrazioni di schema.

Cosa definisci in anticipo

Solo la chiave primaria: una chiave di partizione (obbligatoria) e una chiave di ordinamento opzionale, più i loro tipi. Tutto il resto è arbitrario. Non dichiari colonne.

Cosa varia da item a item

Due Item qualsiasi nella stessa tabella possono avere attributi completamente diversi. Un item potrebbe contenere email e status; un altro potrebbe contenere orderTotal e una map address annidata. DynamoDB memorizza qualunque cosa tu scriva.

Dove si ferma lo schemaless

Lo schemaless ha un confine preciso. La chiave primaria è validata a ogni scrittura; nient'altro lo è. Due Item senza alcun attributo in comune finiscono nella stessa tabella senza proteste:

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']}
    }
  })
);

Riescono entrambe. Ora scrivi la stessa chiave di partizione come numero anziché come stringa:

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

E ometti del tutto pk:

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

Quei due rifiuti sono tutto lo schema. L'attributo chiave deve essere presente e deve corrispondere al tipo dichiarato in AttributeDefinitions. Tutto ciò che va oltre è accettato così com'è scritto.

Passa anche un refuso. Nulla ti dice in scrittura che staus doveva essere status.

Perché aiuta

Niente migrazioni — aggiungi o rimuovi attributi in qualsiasi momento.
Entità miste — molti tipi di entità possono condividere una tabella (single-table design).
Evolvibile — il modello cambia insieme ai requisiti.

È la tua applicazione, non il database, a far rispettare qualsiasi forma su cui fai affidamento.

Cosa lo schemaless non allenta

Lo schemaless vale solo per gli attributi non-chiave. Ogni altro limite di DynamoDB resta vincolante:

400 KB per item — nomi e valori degli attributi contano entrambi verso il tetto.
32 livelli di annidamento per map e list dentro un valore.
65.535 byte di lunghezza massima per un singolo nome di attributo.
25 item al massimo per chiamata BatchWriteItem.

Puoi mettere una stringa status su un item e ometterla sul successivo, ma non puoi memorizzare un blob da 500 KB in nessuno dei due. Usa il calcolatore di dimensione item per misurare un payload prima di scriverlo, e leggi il single-table design quando mescoli tipi di entità in una tabella.

In DynoTable: apri Impostazioni su qualsiasi tabella e indicizzala. Lo schema inferito è costruito da item campionati ed etichettato con onestà — mostra ciò che hai scritto, non ciò che hai dichiarato. Vedi Panoramica e indicizzazione della tabella per come l'indice locale campiona e si aggiorna.

Approfondisci

Vedi il single-table design e il pattern dell'attributo type per gli Item misti. Scarica DynoTable per ispezionare le forme reali degli Item.

Riferimenti

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.

Riprodotto il 2026-07-28 contro DynamoDB Local 3.3.0 tramite @aws-sdk/client-dynamodb 3.1095.0 su Node v24.18.0. Entrambi i messaggi ValidationException sono output del motore riportato alla lettera.