Limiti e quote di DynamoDB, verificati contro il servizio live
Quali sono i limiti di DynamoDB?
Un item è limitato a 400 KB, una partition key a 2.048 byte e una sort key a 1.024 byte. Una batch write accetta 25 item, una batch get 100 chiavi, una transazione 100 azioni. Una tabella ha 20 indici secondari globali e 5 locali. Ognuno di questi numeri in questa pagina è stato stabilito inviando la richiesta ad Amazon DynamoDB e leggendo cosa tornava indietro.
Come sono stati stabiliti questi numeri
AWS pubblica le sue quote senza prove, e di norma va bene così — finché un numero non diventa portante per una decisione di progettazione e vuoi sapere se significa 400.000 byte o 409.600, se conta i nomi dei tuoi attributi, e cosa dice esattamente il servizio quando lo superi.
Quindi li abbiamo testati. Per ogni limite nella prima tabella qui sotto, è stata
costruita una richiesta per posizionarsi esattamente sul valore documentato e
inviata al servizio live in us-east-1; poi una seconda richiesta, un'unità oltre.
La prima deve essere accettata e la seconda rifiutata — è quella coppia a
localizzare il confine, invece di fidarsi della parola della documentazione. Il
messaggio di rifiuto nell'ultima colonna è la frase stessa del servizio, catturata
testualmente e mai ritrascritta.
Quattro righe potevano essere stabilite solo dal lato del rifiuto. Sono i limiti di
CreateTable il cui lato di accettazione significherebbe costruire una tabella con
venti indici e aspettare che ognuno diventi attivo, per un numero che il rifiuto
dichiara esplicitamente. La colonna Come è stato stabilito dice quale è quale;
non è decorazione.
Limiti verificati
| Limite | Valore | Come è stato stabilito | Cosa restituisce il servizio quando lo superi |
|---|---|---|---|
| Dimensione massima dell'item | 409.600 byte | Accettato a 409.600, rifiutato a 409.601 | ValidationException: Item size has exceeded the maximum allowed size |
| Valore massimo della partition key | 2.048 byte | Accettato a 2.048, rifiutato a 2.049 | ValidationException: One or more parameter values were invalid: Size of hashkey has exceeded the maximum size limit of2048 bytes |
| Valore massimo della sort key | 1.024 byte | Accettato a 1.024, rifiutato a 1.025 | ValidationException: One or more parameter values were invalid: Aggregated size of all range keys has exceeded the size limit of 1024 bytes |
| Profondità massima di annidamento | 32 livelli | Accettato a 32, rifiutato a 33 | ValidationException: 1 validation error detected: Nesting Levels have exceeded supported limits: Attributes in the item have nested levels beyond supported limit |
| Lunghezza massima dell'espressione | 4.096 byte | Accettato a 4.096, rifiutato a 4.097 | ValidationException: 1 validation error detected: Invalid ConditionExpression: Expression size has exceeded the maximum allowed size; |
| Item massimi per BatchWriteItem | 25 item | Accettato a 25, rifiutato a 26 | ValidationException: 1 validation error detected: Value '<your request>' at 'requestItems' failed to satisfy constraint: Map value must satisfy constraint: [Member must have length less than or equal to 25, Member must have length greater than or equal to 1] |
| Chiavi massime per BatchGetItem | 100 item | Accettato a 100, rifiutato a 101 | ValidationException: 1 validation error detected: Value at 'RequestItems.<table-name>.member.Keys' failed to satisfy constraint: Member must have length less than or equal to 100 |
| Azioni massime per TransactWriteItems | 100 item | Accettato a 100, rifiutato a 101 | ValidationException: 1 validation error detected: Value '<your request>' at 'transactItems' failed to satisfy constraint: Member must have length less than or equal to 100 |
| Indici secondari globali per tabella | 20 | Solo rifiuto | ValidationException: One or more parameter values were invalid: GlobalSecondaryIndex count exceeds the per-table limit of 20 |
| Indici secondari locali per tabella | 5 | Solo rifiuto | ValidationException: One or more parameter values were invalid: Number of LocalSecondaryIndexes exceeds per-table limit of 5 |
| Attributi non chiave proiettati per indice | 20 | Solo rifiuto | ValidationException: 1 validation error detected: Value '<your request>' at 'globalSecondaryIndexes.1.member.projection.nonKeyAttributes' failed to satisfy constraint: Member must have length less than or equal to 20 |
| Attributi non chiave proiettati per tabella | 100 | Solo rifiuto | ValidationException: One or more parameter values were invalid: Number of projected attributes in all indexes exceeds limit of 100, number of projected attributes:120 |
Ambiente: Amazon DynamoDB, servizio live, us-east-1, testato il 2026-08-27 con
l'AWS SDK for JavaScript v3.
Cosa hanno rivelato i probe
400 KB significa 409.600 byte, e conta i nomi dei tuoi attributi. Un item misurato a esattamente 409.600 byte è stato accettato; 409.601 è stato rifiutato. La misurazione conta la lunghezza UTF-8 di ogni nome di attributo più ogni valore, che è la stessa contabilità implementata dal nostro calcolatore delle dimensioni dell'item — il probe costruisce il suo payload con quella libreria, quindi i due concordano per costruzione e non per asserzione. Il problema di modellazione più profondo dietro questo limite ha una propria guida: il limite di dimensione dell'item DynamoDB.
Il limite di attributi proiettati che tutti citano è quello sbagliato. La pagina
AWS delle
Quote
documenta una sola cifra — "up to 100 attributes combined for all of a table's local
and global secondary indexes" — e non menziona mai un limite per indice. Ce n'è uno,
ed è 20. Una CreateTable che proietta 21 attributi non chiave in un singolo
indice viene rifiutata ben prima che il totale per tabella sia vicino a 100. Il 20 è
documentato, ma solo nella pagina
Projection
dell'API Reference, come vincolo sui membri dell'array: "Maximum number of 20
items". Se progetti un indice basandoti solo sulla pagina delle Quote, l'API
rifiuterà uno schema che la pagina delle Quote dice essere corretto. Entrambi i
numeri sono nella tabella sopra, ciascuno con il rifiuto che lo dimostra.
Due dei messaggi contengono errori di battitura di AWS stessa, riprodotti qui
invece di correggerli silenziosamente — maximum size limit of2048 bytes manca di
uno spazio, e number of projected attributes:120 ne manca un altro. Se stai
facendo grep dei log per queste stringhe, cerca ciò che il servizio invia
davvero, non ciò che si legge correttamente.
Le sort key vengono misurate in aggregato. Il rifiuto per la sort key dice "Aggregated size of all range keys", non "la sort key", perché lo stesso budget di 1.024 byte copre la sort key della tabella e di ogni indice secondario locale in cui finisce l'item.
La pagina da 1 MB, che non solleva alcun errore
Ogni limite sopra si annuncia rifiutandoti. Il limite di pagina di Query e Scan no.
Superalo e DynamoDB restituisce una pagina corta e una LastEvaluatedKey, senza
errore e senza avviso — ecco perché "la mia Scan ha restituito solo parte della
tabella" è una sorpresa così comune, e perché
la paginazione non è opzionale.
Questo significa anche che non c'è nessun messaggio di errore da citare, quindi è stato misurato invece che provocato:
A 1.000 byte per item, una pagina ha contenuto 1.029 item e ha restituito
una LastEvaluatedKey — 1.029.000 byte di dati item, con il 1.030° item lasciato
per la richiesta successiva. A 5.000 byte per item, una pagina ha contenuto
208 item e ha restituito una LastEvaluatedKey — 1.040.000 byte di dati item,
con il 209° item lasciato per la richiesta successiva.
Nessuna delle due pagine conteneva 1 MiB di dati item — la prima ne mancava di circa 19.576 byte. Quindi il budget di pagina addebita più per item dei soli byte dell'item.
Due probe a dimensioni di item diverse bastano per determinarlo. Trattando una
pagina come item × (byte dell'item + overhead per item) ≤ budget, solo 7
overhead in byte interi sono coerenti con entrambe le misurazioni, ed esattamente
uno di essi porta il budget su un megabyte binario tondo: un overhead di 19 byte
per item, con il budget tra 1.048.551 e 1.048.971 byte — un intervallo che
contiene 1.048.576. L'"1 MB" di DynamoDB è binario, come dichiara la sua
stessa pagina delle quote, ed è speso in byte dell'item più overhead per item.
Preventiva circa 19 byte per item.
Quote che non abbiamo testato
I limiti qui sotto sono citati da AWS, non misurati. Sono quote a livello di account: la maggior parte è regolabile su richiesta, e raggiungerle significa mettere in provisioning throughput fatturato all'ora, creare migliaia di tabelle, o impegnarsi in un anno di capacità riservata. Niente di tutto questo è un probe, quindi niente di tutto questo è presentato come tale. La fonte per ogni riga è la pagina AWS Quote in Amazon DynamoDB.
| Quota | Valore predefinito | Regolabile | Perché non l'abbiamo testata |
|---|---|---|---|
| Tabelle per account per regione | 2.500 | Sì | Creare 2.500 tabelle per vedere fallire la 2.501ª lascia un account che qualcuno deve poi smontare. |
| Throughput con provisioning per tabella | 40.000 RCU e 40.000 WCU | Sì | Mettere in provisioning 40.000 unità fattura all'ora, che venga fatta o meno una singola richiesta. |
| Throughput con provisioning per account | 80.000 RCU e 80.000 WCU | Sì | Stesso motivo, raddoppiato — e cambia un'impostazione a livello di account. |
| Throughput on-demand per tabella | 40.000 RRU e 40.000 WRU | Sì | Raggiungerlo significa sostenere 40.000 richieste al secondo, che è un load test con una fattura. |
| Capacità riservata attiva per account | 1.000.000 unità di capacità | Sì | La capacità riservata è un impegno d'acquisto di un anno, non un probe. |
| Dimensione della tabella | Nessun limite pratico | — | AWS dichiara che le tabelle non sono vincolate in item né in byte; non c'è un confine da trovare. |
Su quali limiti dovresti progettare
La maggior parte di questi non li incontrerai mai. Il pugno di limiti che plasmano progetti reali:
- 400 KB per item è un vincolo di modellazione, non una quota. Un item che vi si avvicina è di solito una relazione uno-a-molti illimitata memorizzata come lista incorporata. Vedi il limite di dimensione dell'item.
- La pagina da 1 MB governa ogni Query e Scan che scrivi. Un codice che
ignora
LastEvaluatedKeyè silenziosamente sbagliato il giorno in cui i tuoi dati superano una pagina. - 25 item per batch write e 100 per batch get plasmano i tuoi loop di caricamento massivo. Vedi le operazioni batch.
- 100 azioni per transazione è quello che la gente incontra provando a far comportare DynamoDB in modo relazionale. Vedi le transazioni.
- 20 GSI, 5 LSI, 100 attributi proiettati vincolano la progettazione dei pattern di accesso molto più spesso delle quote di throughput, e il numero di LSI è fisso nel momento in cui la tabella viene creata. Vedi le proiezioni degli indici e GSI contro LSI.
La maggior parte dei rifiuti citati sopra ha anche una propria pagina sotto
Errori DynamoDB, con la richiesta che produce ciascuno di
essi. I quattro rifiuti di CreateTable non ce l'hanno — sono stati catturati
per questa pagina.
Per controllare un singolo item contro la soglia dei 400 KB senza scriverlo, il calcolatore delle dimensioni dell'item gira nel tuo browser. Per guardare gli item nelle tue tabelle, DynoTable è un client desktop per DynamoDB.