DynamoDB è un database relazionale?

No. DynamoDB non è un database relazionale — è un archivio NoSQL chiave-valore e di documenti. Non ci sono tabelle con schemi fissi, non ci sono chiavi esterne e non ci sono join. Modelli i dati attorno ai pattern di accesso della tua applicazione e denormalizzi, invece di normalizzare tra tabelle correlate come faresti in un database relazionale (SQL). Se ti manca il flusso di lavoro relazionale, DynoTable ne riporta un po' sul client: un SQL Workbench che esegue veri JOIN e GROUP BY, e le Smart Table che uniscono le tabelle visivamente.

Perché non è relazionale

I database relazionali impongono uno schema, normalizzano i dati su molte tabelle e le uniscono al momento della lettura. DynamoDB fa l'opposto: memorizza Item senza schema e si aspetta che tu faccia il join in anticipo duplicando o incorporando i dati correlati.

Cosa sostituisce le funzionalità relazionali

Join → denormalizzazione e single-table design.
Tabelle normalizzate → collezioni di Item raggruppate sotto un'unica chiave di partizione.
SQL ad-hoc → Query e Scan basati su chiave, o PartiQL (un sottoinsieme compatibile con SQL, comunque senza join).

Per inciso, PartiQL non colma il divario. Il suo parser rifiuta una SELECT su due tabelle e rifiuta GROUP BY, entrambe prima di leggere qualsiasi cosa; i rifiuti esatti sono citati in DynamoDB supporta i join e DynamoDB supporta SQL.

Quanto ti costa davvero denormalizzare

Il compromesso viene di solito descritto come "duplica i dati invece di fare join", il che suona come una decisione sullo storage. In realtà è una decisione su scritture e atomicità, ed è la parte che i motori relazionali ti nascondono.

Prendi un cliente con 5.000 ordini, e il cliente cambia il nome visualizzato. In uno schema relazionale è un solo UPDATE su una sola riga, e ogni join raccoglie subito il nuovo valore. Denormalizzato in DynamoDB, il nome vive su tutti e 5.000 gli Item degli ordini, quindi la rinomina sono 5.000 scritture di Item: 5.000 unità di scrittura, circa $0.003 in on-demand su us-east-1 a 1 KB per Item.

I soldi non sono nulla. Il problema è che non può essere un'unica operazione. TransactWriteItems si ferma a 100 azioni, quindi 5.000 Item sono almeno 50 transazioni separate, e non c'è isolamento tra di esse. Per tutto il tempo in cui quel fan-out gira, i tuoi stessi dati sono in disaccordo tra loro, e qualsiasi lettura che atterri a metà corsa vede un misto di nomi vecchi e nuovi.

I database relazionali ti comprano esattamente quello: un unico cambiamento atomico su un'unica copia autorevole. Rinunciarci è il vero prezzo del biglietto, ed è il motivo per cui "quali attributi vengono duplicati" merita più attenzione in fase di progettazione di quali vengono indicizzati.

Approfondisci

Leggi come modellare i dati in DynamoDB e single-table design. Scarica DynoTable per esplorare visivamente il tuo modello dei dati — ed eseguirci sopra query JOIN/GROUP BY in stile relazionale con il SQL Workbench.

Riferimenti

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra; il tetto di 100 azioni per transazione è stato riconsultato nel riferimento dell'API il 2026-07-28.