DynamoDB può memorizzare blob?

Sì, entro certi limiti. DynamoDB memorizza oggetti binari di grandi dimensioni (BLOB) in attributi Binary (B), codificati in base64 sul filo, purché l'intero Item resti sotto i 400 KB. Per qualsiasi cosa più grande — video, audio, immagini ad alta risoluzione — AWS consiglia di memorizzare il blob in Amazon S3 e di tenere in DynamoDB solo un riferimento e i metadati.

Memorizzare un blob direttamente

Metti i byte in un attributo Binary. Le applicazioni codificano in base64 i valori binari prima di inviarli; DynamoDB conteggia la lunghezza in byte grezzi ai fini del limite di 400 KB per Item. I blob piccoli (firme, payload compatti) ci stanno comodamente.

Quanti byte ci stanno davvero

I 400 KB sono l'Item, non il blob. Cercando il confine per bisezione si ottiene un tetto esatto: un Item che contiene solo una partition key di un carattere e un attributo Binary prende 409.594 byte di blob. Un byte in più e la scrittura fallisce:

ValidationException: Item size has exceeded the maximum allowed size

Sei attributi di metadati realistici accanto a esso (tipo di contenuto, dimensioni, chi ha caricato, timestamp) costano 94 byte e abbassano il tetto a 409.500.

La codifica base64 è un dettaglio di trasporto e nient'altro. Quel put da 409.594 byte invia 546.128 byte di base64 nel corpo della richiesta e DynamoDB lo accetta, quindi l'idea ampiamente ripetuta che il base64 si mangi un terzo del tuo budget è sbagliata. Quello che costa davvero è il throughput: un blob a piena dimensione sono 400 unità di scrittura per put e 100 unità di lettura per una lettura fortemente coerente, contro 1 e 0,5 di un Item piccolo.

Il pattern degli oggetti grandi

Quando un blob supera i 400 KB:

Memorizza l'oggetto in Amazon S3.
Tieni in DynamoDB la chiave S3 più i metadati (nome, dimensione, proprietario, timestamp).

Questo accoppia i lookup indicizzati veloci di DynamoDB con lo storage di oggetti economico e senza limiti di S3. Per dati che superano il limite solo di poco, AWS suggerisce anche di comprimere gli attributi grandi (output GZIP o LZO memorizzato in un attributo Binary) o di suddividerli su più Item.

La compressione salva il testo, non i media

Quel consiglio sulla compressione funziona esattamente su un tipo di blob. gzip -9 su un lockfile YAML da 614.499 byte restituisce 164.302 byte, un taglio del 73% che lo porta da impossibile a comodo. Lo stesso comando su un PNG da 794.311 byte restituisce 785.175 byte, un risparmio dell'1,2%, perché il formato si era già compresso da solo. Quindi la compressione ti compra spazio per log, payload JSON e testo, e non ti compra nulla per i file multimediali che sono il motivo tipico per cui si sbatte contro il limite.

Un'avvertenza

Non esistono transazioni tra servizi diversi tra DynamoDB e S3, quindi la tua applicazione deve gestire da sé i fallimenti parziali e gli oggetti orfani.

Approfondisci

Verifica le dimensioni con il calcolatore della dimensione degli Item e leggi la guida sul limite di dimensione degli Item. Scarica DynoTable per visualizzare i dati binari.

Riferimenti

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

Misurato il 2026-07-28 su DynamoDB Local 3.3.0 tramite @aws-sdk/client-dynamodb 3.1095.0 — entrambi i tetti in byte sono stati trovati per bisezione anziché derivati, e le cifre di gzip provengono dall'esecuzione di gzip -9 sui due file descritti. Il motore di produzione di AWS potrebbe formulare i propri rifiuti in modo diverso.