Si può eseguire DynamoDB in locale?

Sì. AWS distribuisce DynamoDB Local, una versione scaricabile e gratuita di DynamoDB che gira sulla tua macchina come immagine Docker, eseguibile Java o dipendenza Apache Maven. Espone la stessa API del servizio web, quindi puoi sviluppare e testare offline, poi semplicemente puntare il tuo codice ad AWS.

Tre modi per eseguirlo

Immagine Docker — la scelta più comune: un docker run e l'endpoint è attivo su una porta locale.
Archivio scaricabile — un'applicazione Java che avvii direttamente (richiede una JRE).
Dipendenza Apache Maven — incorporalo nelle suite di test JVM.

Perché sviluppare in locale

Il database è autocontenuto sul tuo computer, quindi risparmi sui costi di throughput, storage e trasferimento dati — e non ti serve una connessione internet mentre sviluppi. Quando sei pronto a fare il deploy, rimuovi l'endpoint locale dal codice e punta al servizio web DynamoDB.

Attenzione alle differenze

DynamoDB Local emula l'API, ma non è il motore di produzione — AWS documenta differenze di comportamento nelle sue note d'uso (il throughput non viene applicato, per esempio). Trattalo come un doppio funzionale per sviluppo e test, non come un modello di prestazioni.

Tre divergenze che abbiamo misurato

Teniamo un container DynamoDB Local in esecuzione per riprodurre gli errori citati sulle nostre pagine sugli errori, il che significa che ne tocchiamo i bordi regolarmente. Tre vale la pena conoscerle prima di fidarti di un test locale verde.

Il throughput con provisioning non viene applicato affatto. Abbiamo creato una tabella a 1 RCU, inserito un item da 3,5 KB e lo abbiamo riletto in modo fortemente coerente in un loop con i retry dell'SDK disattivati (maxAttempts: 1):

reads=5000 ok=5000 errors=0 elapsed=2.5s rate=1997/s

Cinquemila letture, zero throttle, circa 2.000 unità di lettura al secondo sostenute contro una tabella con provisioning per una. Lo stesso loop contro il servizio live solleva ProvisionedThroughputExceededException alla lettura 49. Un bug di capacità non può fallire in locale.

Un errore cambia nome. Esegui lo stesso INSERT PartiQL due volte e DynamoDB Local risponde DuplicateItem con il messaggio Duplicate primary key exists in table. Il servizio risponde DuplicateItemException con There was an attempt to insert an item with the same primary key as an item that already exists in the DynamoDB table. Una gestione degli errori che si basa sul nome passa in locale e sbaglia in produzione.

Alcune API sono semplicemente assenti. ExportTableToPointInTime risponde:

UnknownOperationException: An unknown operation was requested.

Non è l'errore del servizio per la stessa chiamata, quindi nemmeno un percorso di codice che si protegge da PointInTimeRecoveryUnavailableException può essere esercitato in locale.

Approfondisci

La guida a DynamoDB Local illustra la configurazione passo dopo passo, e la guida alla connessione locale e a LocalStack mostra come puntarci una GUI — DynoTable si connette agli endpoint locali esattamente come si connette ad AWS. Prova la tua prima query con il generatore di espressioni.

Riferimenti

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

Le tre divergenze sono state riprodotte il 2026-07-28 contro DynamoDB Local 3.3.0 (amazon/dynamodb-local, Corretto 17.0.17) con @aws-sdk/client-dynamodb 3.1095.0 su Node v24.18.0. Ogni riga di output qui sopra è del motore stesso, non modificata.