Quando non dovresti usare DynamoDB?

Evita DynamoDB quando il tuo carico di lavoro è analitico o i tuoi pattern di accesso sono sconosciuti. DynamoDB è costruito su misura per carichi operativi (OLTP) con pattern di accesso noti e basati su chiave — non ha join né funzioni di aggregazione, e le query ad-hoc ricadono su costosi scan dell'intera tabella. Per la reportistica OLAP o per esigenze relazionali in evoluzione, scegli un altro motore.

Casi in cui non è adatto

  • Analisi e reportistica ad-hoc (OLAP) — non esistono GROUP BY, SUM o AVG; ogni rollup è uno scan o un aggregato precalcolato che mantieni tu. Vedi la guida alle aggregazioni per gli aggiramenti.
  • Schemi relazionali normalizzati — DynamoDB omette deliberatamente l'operatore JOIN; la guida di AWS stessa è di denormalizzare.
  • Pattern di accesso sconosciuti o in rapida evoluzione — progetti le chiavi attorno alle query. Quando non sai ancora nominare le query, ogni nuova query rischia una riprogettazione della tabella o uno scan completo.
  • Ricerca full-text e query ricche — vedi DynamoDB supporta la ricerca full-text?; la ricerca appartiene a un indice di ricerca.
  • Oggetti grandi — gli Item si fermano a 400 KB; i file multimediali e i documenti appartengono a S3 con un puntatore nella tabella.

Il rollup, prima rifiutato e poi quotato

Il disallineamento con l'analitica non è una questione di gusti. Chiedi a DynamoDB un conteggio raggruppato in PartiQL e l'istruzione viene rifiutata prima di leggere qualsiasi cosa:

SELECT status, COUNT(*) FROM "orders" GROUP BY status
ValidationException: Unsupported clause: GROUP BY
HTTP 400

Togli il raggruppamento e chiedi il semplice totale, e fallisce un passo prima, nel parser:

SELECT COUNT(*) FROM "orders"
ValidationException: Unexpected path component at 1:8:5
HTTP 400

COUNT non è affatto una funzione in questo dialetto, quindi il parser lo legge come un percorso di attributo e si arrende alla parentesi.

Resta lo Scan che scrivi tu, e ha un prezzo. Leggere una tabella da 50 GB da cima a fondo costa 6.553.600 unità di lettura a coerenza eventuale, ossia la dimensione aggregata scansionata in unità da 4 KB, dimezzata. In on-demand su us-east-1 sono 0,82 $.

Aggiorna quel numero una volta all'ora e diventano $598 al mese. Mantenere il contatore man mano che scrivi, o esportare verso un archivio analitico, è la risposta più economica, ed entrambe sono lavoro che DynamoDB non sta facendo per te.

Dove eccelle

L'elenco inverso è esattamente il punto forte di DynamoDB: carichi operativi ad alto volume con letture e scritture prevedibili basate su chiave che devono restare a millisecondi a una cifra a qualsiasi scala — carrelli, sessioni, profili, stato di gioco, eventi IoT. La guida su quando usare DynamoDB costruisce il caso a favore.

Approfondisci

Se sei indeciso, leggi poi quando usare DynamoDB. Sei già su DynamoDB e ti manca SQL? DynoTable esegue JOIN e GROUP BY su tabelle live dal desktop — e il calcolatore dei prezzi ti dice quanto costerebbe il tuo carico di lavoro prima che tu ti impegni.

Riferimenti

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra. La cifra di 400 KB è stata riconfermata il 2026-07-28; AWS l'ha spostata dalla pagina delle service quota dentro Constraints.html.

Riprodotto il 2026-07-28 su DynamoDB Local 3.3.0 tramite @aws-sdk/client-dynamodb 3.1095.0 su Node v24.18.0; entrambi i messaggi di ValidationException sono riportati alla lettera. Il costo dello Scan è calcolato dalle tariffe us-east-1 nella nostra tabella prezzi AWS sincronizzata.

Lavora con DynamoDB senza la Console

Un client desktop veloce per DynamoDB che esegue il vero SQL che DynamoDB non può — JOINs, GROUP BY, aggregazioni — con modifica visuale e un agente AI sulle tue chiavi Bedrock.

Prova gratuita di 30 giorni, senza carta di credito — poi il piano Free senza limiti di tempo.