Quanto è veloce DynamoDB?

Veloce. DynamoDB offre una latenza costante di lettura e scrittura di millisecondi a una cifra a qualsiasi scala. Aggiungere DynamoDB Accelerator (DAX), una cache in memoria, porta le letture a coerenza eventuale a microsecondi. Le prestazioni restano piatte man mano che le tabelle crescono perché le letture puntano direttamente a una chiave di partizione anziché scansionare, quindi la latenza non peggiora con il volume dei dati.

Perché resta veloce su larga scala

Un GetItem o una Query calcolano l'hash della chiave di partizione e vanno dritti alla partizione fisica giusta. Non scansionano mai l'intera tabella, quindi il tempo di risposta è pressoché costante che la tabella abbia migliaia o miliardi di Item.

Letture in microsecondi con DAX

DAX è una cache in memoria completamente gestita e compatibile con DynamoDB che si mette davanti alla tua tabella. Restituisce le letture a coerenza eventuale in microsecondi — fino a un miglioramento di 10 volte rispetto ai millisecondi — senza invalidazione della cache da gestire. Non è adatta ai carichi di lavoro che hanno bisogno di letture fortemente coerenti.

Il numero che i tuoi utenti vedono davvero

I millisecondi a una cifra sono misurati all'endpoint DynamoDB. Quello che la tua applicazione sperimenta è quello più la rete, e la rete di solito è la metà più grande, di gran lunga.

Misurato da una macchina in Spagna il 2026-07-28, nove campioni per regione, mediana dell'handshake TCP verso ciascun endpoint DynamoDB regionale. È un round trip, prima che sia inviato un solo byte di richiesta:

Regione	Mediana handshake TCP
eu-central-1 (Francoforte)	46,6 ms
eu-south-2 (Spagna)	49,1 ms
eu-west-1 (Irlanda)	53,8 ms
us-east-1 (N. Virginia)	113,6 ms
ap-northeast-1 (Tokyo)	259,5 ms

Una macchina, un ISP, un pomeriggio: leggili come ordini di grandezza anziché come un benchmark. Due cose in essi valgono in generale. Un round trip transatlantico è più di dieci volte la lettura che trasporta, quindi a quella distanza la latenza di DynamoDB è un errore di arrotondamento nella tua. E la regione geograficamente più vicina alla macchina non è stata la più veloce da essa: eu-south-2 sta in Spagna e non ha misurato meglio di Francoforte, perché a decidere è il routing, non la distanza.

La versione pratica è che co-localizzare il calcolo con la tabella batte qualsiasi ottimizzazione di DynamoDB tu possa fare. Una funzione Lambda nella regione della tabella paga una frazione dei numeri qui sopra; un laptop o un job di CI su un altro continente li paga tutti a ogni connessione, ed è anche il motivo per cui il riuso della connessione dell'SDK conta più di quanto sembri.

Cosa può rallentarti

Scan e filtri — leggere l'intera tabella è lento e costoso; progetta invece un accesso basato su chiave.
Partizioni hot — quando una chiave di partizione attira molto più traffico della sua quota, le richieste verso di essa vengono sottoposte a throttling anche se la capacità complessiva della tabella è a posto.

È una buona progettazione delle chiavi, non più hardware, a mantenere DynamoDB veloce.

Approfondisci

Leggi query vs scan ed evita una partizione hot. Scarica DynoTable per vedere quali letture girano come Query e quali come Scan.

Riferimenti

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

Cifre di latenza misurate il 2026-07-28 da una singola macchina in Spagna con curl, nove richieste per regione, riportando la mediana di time_connect meno time_namelookup contro https://dynamodb.<region>.amazonaws.com. Due esecuzioni indipendenti hanno concordato entro 3 ms.