MongoDB o DynamoDB: quale database NoSQL scegliere?

MongoDB e DynamoDB sono due database NoSQL che competono davvero per la stessa decisione, e differiscono in quasi tutto il resto. MongoDB conserva documenti in forma JSON e li interroga con un linguaggio ricco: filtri su qualunque campo, aggregazioni, indici che si aggiungono quando il bisogno emerge. Gira dove vuoi, su una macchina in sala server, dentro un container o su un servizio gestito. DynamoDB è il database gestito di AWS, pensato per l'accesso per chiave, e chiede in cambio una progettazione diversa: gli schemi di accesso si decidono prima, perché la chiave primaria e gli indici secondari locali nascono con la tabella e non si aggiungono dopo. Il servizio gestito esiste inoltre solo dentro AWS: DynamoDB Local serve a sviluppare e provare, non a mandare in produzione altrove. Appartengono alla stessa famiglia descritta in relazionale, NoSQL, vettoriale o a grafo, ma la somiglianza finisce lì.

Due chiarimenti bastano a smontare due equivoci ricorrenti. Gli indici secondari globali si aggiungono a tabella viva, ma proiettano una copia dei dati, con costo e consistenza propri: correggono una previsione sbagliata, non tolgono il bisogno di farla. E la compatibilità non è il servizio: ExtendDB, il progetto Apache 2.0 con cui AWS ne ha aperto le API nel 2026, permette, per ora in versione iniziale, di far girare altrove un carico scritto per DynamoDB, ma non porta con sé le garanzie e la scala del servizio gestito.

Portabilità o integrazione gestita

È questa la decisione che il confronto tecnico nasconde. Il servizio gestito non si sposta: sceglierlo significa accettare che quel pezzo di applicazione non cambi fornitore senza cambiare le garanzie operative su cui conta, ed è un caso da manuale di dipendenza dal fornitore. Non è di per sé un difetto: chi vive già dentro AWS riceve in cambio identità, cifratura, backup e scalabilità senza amministrare niente. MongoDB gira ovunque, e quella portabilità è il suo argomento principale. Il rovescio è la licenza, ed è il punto che le trattazioni in inglese quasi non toccano: dal 2018 il server della Community Edition è distribuito sotto SSPL, una licenza source-available che l'Open Source Initiative non riconosce come open source, perché impone obblighi a chi offre quel software come servizio gestito. Chi sceglie MongoDB "perché è open source" sta usando un'informazione superata. La clausola non colpisce l'azienda che usa il database dentro la propria applicazione, ma la distinzione va letta, non assunta: le famiglie di licenza sono in licenza software.

Un esempio enterprise

Un distributore di ricambi tiene su MongoDB il catalogo prodotti: schede con attributi diversi per famiglia merceologica, ricerche per combinazioni che il marketing inventa ogni trimestre, un motore che deve rispondere a domande non previste. Sulla telemetria dei muletti di magazzino, invece, la domanda è sempre la stessa, cioè lo storico di un mezzo in un intervallo di tempo, e il volume cresce senza limite: lì DynamoDB dentro un'architettura già AWS costa meno fatica operativa. La decisione non è stata "quale database è migliore", ma quale dei due carichi tollerava di essere legato a un fornitore. Il catalogo alimenta il sito e finirà altrove; la telemetria resta dove nasce.

Perché conta per chi decide

Le domande da porsi sono tre, e nessuna riguarda le prestazioni. Le query di questa applicazione sono note in anticipo o cambieranno con il business? Questo componente deve poter uscire dal cloud in cui si trova, e in quanti mesi? Chi rivende il nostro prodotto lo ospita per conto terzi, cioè siamo davvero fuori dalla clausola della licenza? Chi ha bisogno di transazioni con le garanzie ACID le trova in entrambi, con ambiti e costi diversi, quindi non è quello il criterio. Il criterio è dove vuoi che stia il vincolo: nel codice che scrivi o nel contratto che firmi.