Il limite di 400 KB per gli item DynamoDB

Un singolo item di DynamoDB può contenere al massimo 400 KB di dati. Venendo da MongoDB (documenti da 16 MB) o da una riga relazionale senza un tetto pratico, quel limite sembra basso — e tendi a scoprirlo nel modo più duro, quando una scrittura che ha funzionato per mesi improvvisamente fallisce con una ValidationException perché un item è finalmente cresciuto troppo.

Il limite non è arbitrario, e non è una quota che puoi aumentare. È un vincolo di modellazione, e gli item che lo raggiungono di solito ti stanno dicendo che i dati erano modellati male.

Qual è la dimensione massima di un item in DynamoDB?

DynamoDB limita un singolo item a 400 KB — un limite rigido che non puoi aumentare. La dimensione conta i nomi degli attributi più i valori insieme, inclusi ogni elemento di lista, mappa e set nidificato. Gli item di solito lo raggiungono attraverso una crescita illimitata, come una lista incorporata in continua espansione; la soluzione è la modellazione, dividere la collezione in item separati, non la compressione.

• 400 KB per item, tetto rigido. Non regolabile, non una quota morbida.
• Dimensione = nomi degli attributi + valori, insieme. I nomi lunghi degli attributi contano, su ogni item.
• Anche nidificazione e set contano. Liste, mappe e i loro valori nidificati si sommano tutti.
• La causa usuale è la crescita illimitata — incorporare una lista che cresce senza limite su un item genitore.
• La soluzione è la modellazione, non la compressione. Dividi la collezione in crescita nei suoi item sotto una partition key condivisa.

Il problema: l'item che cresce per sempre

Supponi di tracciare una flotta di veicoli, e decidi di memorizzare le letture di telemetria di ogni veicolo come una lista sull'item del veicolo:

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

Per un giorno o due va bene. Ma le letture arrivano ogni pochi secondi e non si fermano mai, quindi la lista cresce senza limite. Alla fine una lettura in più spingerebbe l'item oltre i 400 KB, e DynamoDB rifiuta la scrittura con una ValidationException: Item size has exceeded the maximum allowed size — non puoi più registrare telemetria per quel veicolo affatto, perché ogni aggiornamento riscrive l'intero item.

Il bug non è il limite di dimensione. È modellare una relazione uno-a-molti illimitata come una lista incorporata. Questo funziona solo quando il lato "molti" è limitato e piccolo.

Cosa concorre effettivamente ai 400 KB

DynamoDB misura la dimensione totale dell'item come la somma di:

• Ogni nome di attributo, codificato in UTF-8. Un nome da 20 caratteri ripetuto su milioni di item è sia dimensione sia storage che paghi — ecco perché i modellatori esperti tengono corti i nomi degli attributi.
• Ogni valore di attributo. Stringhe e binari per la loro lunghezza in byte; i numeri per una codifica compatta; booleani e null per un piccolo costo fisso.
• Struttura nidificata. Una lista o mappa conta il proprio overhead più la dimensione di ogni elemento e chiave al suo interno, fino in fondo.

Non c'è un tetto separato per attributo da pianificare — è l'intero item contro la linea dei 400 KB. La documentazione AWS sulla dimensione degli item esplicita l'esatto conteggio dei byte.

Perché il limite esiste

Gli item grandi sono costosi da spostare. Le letture di DynamoDB sono misurate in unità da 4 KB, quindi un item da 400 KB costa 100 RCU per leggerlo in modo forte — e letture, scritture e replica diventano tutte più lente e costose man mano che gli item crescono. Il tetto ti spinge verso item piccoli e mirati, e lontano dall'anti-pattern del "recupera un unico blob gigante" che i principianti NoSQL adottano per abitudine relazionale.

Modellare per aggirarlo

Per l'esempio della flotta, smetti di incorporare. Dai a ogni lettura il suo item nella stessa partizione del veicolo, ordinato per timestamp sulla sort key:

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

Ora nessun singolo item cresce, le scritture non superano mai il tetto, e una singola Query su VEHICLE#A1 estrae comunque le letture di un veicolo come una collezione di item ordinata. Le sotto-liste limitate (una manciata di tag, un blocco di configurazione fisso) vanno bene da incorporare; quelle illimitate diventano item.

Controllare la dimensione di un item in DynoTable

Prima di impegnarti in una forma, pesa un item rappresentativo. In DynoTable, aprine uno in Quick View e mostra la dimensione in byte dell'item accanto ai suoi attributi — così cogli una forma troppo pesante mentre navighi dati reali, al momento della progettazione invece che alla scrittura fallita.

Preferisci restare nel browser? Il calcolatore di dimensione degli item DynamoDB fa lo stesso da un campione incollato, riportando gli esatti KB e le RCU/WCU che ogni lettura e scrittura costeranno.

Verificato su DynamoDB

Le regole di dimensionamento sono facili da enunciare e facili da sbagliare in modo sottile, quindi abbiamo confrontato le nostre con l'unica autorità che conta: ciò che DynamoDB fattura davvero.

Il punto è che ConsumedCapacity riporta unità anziché byte, e una scrittura di N byte costa ceil(N / 1024) WCU. Grossolano in generale — ma esatto su un confine. Un item costruito per fermarsi esattamente a 1024 byte deve costare 1 WCU, e uno costruito per fermarsi a 1025 deve costarne 2, quindi un errore di un solo byte nel calcolo ribalta il numero osservato.

Sei su sei concordano, e sono le coppie di confine a portare la prova: gli item da 1.024 e 1.025 byte differiscono per un singolo carattere di padding e DynamoDB li addebita in modo diverso, esattamente dove il nostro calcolo dice che cade il gradino.

La conseguenza pratica è quella che costa denaro. Un item di un byte oltre il kilobyte costa una WCU intera in più, e a 4 KB lo stesso scalino compare sul lato lettura — quindi ridurre un item da 1.025 byte a 1.024 dimezza il suo costo di scrittura, mentre gonfiarlo da 1.024 a 1.025 lo raddoppia. I nomi degli attributi concorrono al totale, ed è per questo che accorciare le chiavi su una tabella molto sollecitata non è micro-ottimizzazione.

Insidie + passaggi successivi

• Attento alle liste incorporate che crescono col traffico — sono la classica bomba a orologeria dei 400 KB. Limitale o dividile fuori.
• Accorcia i nomi degli attributi su item ad alta cardinalità — è dimensione e storage recuperati gratis.
• I valori grandi appartengono a S3. Memorizza i blob grandi (immagini, documenti) in S3 e tieni solo la chiave sull'item.
• Correlati: denormalizzazione e relazioni uno-a-molti trattano quando incorporare vs dividere.

Vuoi vedere le dimensioni reali degli item di una tabella a colpo d'occhio? Scarica DynoTable e ispeziona i tuoi dati direttamente.

Valori di capacità verificati il 2026-07-26 sul servizio DynamoDB live in us-east-1 (pnpm content:verify-item-size).