MongoDB vs SQL quando scegliere NoSQL e quando restare sul relazionale

Se stai leggendo questo, probabilmente hai un progetto davanti e un dubbio che abbiamo sentito decine di volte: “MongoDB o MySQL/PostgreSQL?”. Non è una domanda da manuale. È una scelta che impatta i costi di sviluppo, le performance in produzione, la facilità di manutenzione e, alla fine, il conto economico del cliente.

Noi di Meteora Web non abbiamo una risposta fissa. Abbiamo costruito e-commerce su WooCommerce (MySQL) e piattaforme proprietarie su Laravel con PostgreSQL, ma abbiamo anche scelto MongoDB per progetti dove la flessibilità dello schema era più importante della stretta integrità referenziale. E abbiamo visto progetti fallire perché hanno scelto il database sbagliato solo perché “è di moda”.

Questa guida parte dal problema concreto: quando conviene davvero MongoDB e quando invece è meglio restare su un database SQL relazionale? Vediamo i criteri decisionali, gli errori comuni e qualche numero che puoi portare al tuo team o al tuo cliente.

Lo schema è il tuo primo filtro

La differenza fondamentale tra SQL e NoSQL (e MongoDB in particolare) è come gestiscono la struttura dei dati.

In SQL, definisci tabelle, colonne, tipi, chiavi esterne. Ogni riga deve rispettare quello schema. È rigido, prevedibile, potente per integrità. In MongoDB, un documento JSON può avere campi diversi da un altro documento nella stessa collezione. Nessuna migrazione ALTER TABLE, nessun JOIN obbligatorio.

Quando MongoDB vince: i tuoi dati hanno struttura variabile o evolvono rapidamente. Esempio classico: un catalogo prodotti con attributi diversi per categoria (taglia, colore, potenza, materiale). Con SQL dovresti creare tabelle EAV (Entity-Attribute-Value) o decine di colonne opzionali. Con MongoDB, ogni prodotto ha solo i campi che servono.

Quando SQL vince: i dati sono fortemente relazionali e le relazioni sono critiche per l’integrità. Ordini e clienti, fatture e righe, inventory e warehouse. Qui un documento NoSQL può portare a ridondanza, inconsistency, update complessi.

Esempio pratico: e-commerce di abbigliamento

Abbiamo gestito l’ERP di un negozio di abbigliamento reale (Hibrido Abbigliamento). Ogni capo ha taglia, colore, stagione, fornitore, lotto, prezzo di acquisto e vendita. In SQL lo modelli con tabelle normalizzate (prodotto, SKU, variante, magazzino). È pulito, integrato, facile generare report di marginalità per stagione. Con MongoDB dovresti embeddare le varianti dentro il documento prodotto — ok per letture veloci, ma gli update di stock su centinaia di taglie diventano operazioni pesanti e soggette a race condition. Per un negozio di abbigliamento, SQL batte MongoDB 9 volte su 10.

Le query che fai decidono il database

Non è solo lo schema: sono le operazioni che devi eseguire. Se hai bisogno di report aggregati complessi (SUM, GROUP BY, JOIN tra 5 tabelle), SQL è superiore. L’aggregation pipeline di MongoDB è potente ma ha una curva di apprendimento più alta e può diventare lenta su dati relazionali.

Dall’altra parte, se devi leggere un intero oggetto con tutte le sue dipendenze (es. un post del blog con commenti e autore), MongoDB fa una sola query — in SQL servirebbero JOIN o N+1 query.

Regola pratica: se le tue query sono prevalentemente di lettura su dati che hanno una naturale struttura gerarchica, MongoDB è più performante. Se devi fare analisi trasversali, SQL è la scelta.

Misura con numeri reali

Su un nostro progetto con Laravel + PostgreSQL, una query di report mensile su ordini e rimborsi impiega 120ms. Con MongoDB (stessi dati, schema embeddato) la stessa logica di aggregazione richiedeva 800ms e codice più complesso. Abbiamo migrato tutto su Postgres e il cliente ha risparmiato tempo di calcolo e costi di hosting. Il database non si sceglie per moda, si sceglie per il carico di lavoro reale.

Scalabilità e costi: quando il NoSQL fa la differenza

MongoDB è stato progettato per scalare orizzontalmente (sharding) in modo nativo. SQL tradizionale scala verticalmente (più RAM, più CPU su un singolo nodo) o richiede soluzioni complesse come replica e partizionamento manuale. Per applicazioni con volumi enormi di dati (milioni di documenti al giorno), MongoDB può essere più economico e gestibile.

Ma attenzione: per la maggior parte delle PMI italiane, il volume non giustifica la complessità di uno sharded cluster. Un singolo server PostgreSQL con 16 GB di RAM e SSD gestisce agevolmente decine di milioni di righe. Il costo di operatività di un database NoSQL distribuito può superare il beneficio se non hai quel carico.

Noi lo vediamo spesso: clienti che scelgono MongoDB “per scalare”, ma poi hanno 10.000 utenti e pagano un consulente per configurare lo sharding. La scalabilità è un problema di quando arrivi, non di quando inizi.

Integrità referenziale e transazioni

MongoDB ha introdotto le transazioni multi-documento dalla versione 4.0, ma non sono così robuste come quelle ACID di PostgreSQL. Per applicazioni finanziarie, contabili, o dove anche una singola riga fuori posto causa danni, SQL è ancora la scelta sicura.

Veniamo dalla contabilità: bilanci, partita doppia, IVA. Sappiamo quanto costa un errore di integrità. Se i tuoi dati devono essere consistenti al 100%, usa SQL. Se puoi tollerare una eventuale inconsistenza temporanea (es. like su un post), MongoDB va benissimo.

Strumenti e competenze del team

Un fattore spesso sottovalutato: chi lavorerà su quel database? Nel nostro stack usiamo Laravel con Eloquent (ORM) che supporta sia MySQL/PostgreSQL che MongoDB tramite pacchetti come Jenssegers/Mongodb. Ma la maggior parte degli sviluppatori PHP conosce bene SQL. MongoDB richiede familiarità con l’aggregation pipeline, indici composti, geospaziali, etc.

Consiglio operativo: se il tuo team ha più esperienza SQL, resta su SQL. Non inseguire tecnologie per sentirsi moderni. Il database che conosci bene è più produttivo di quello “migliore” che impari a fatica.

Guida pratica alla scelta

Ecco una checklist che usiamo nei nostri progetti:

• I dati hanno una struttura prevedibile e relazioni forti? → SQL (PostgreSQL/MySQL).
• I dati sono eterogenei, con attributi variabili? → MongoDB.
• Hai bisogno di report aggregati complessi? → SQL.
• Devi leggere oggetti annidati completi con molte sotto-entità? → MongoDB.
• Il volume di scritture è altissimo e devi scalare orizzontalmente? → MongoDB.
• Hai requisiti stringenti di integrità transazionale? → SQL.
• Il team è più esperto in SQL? → SQL.

Cosa evitare

• Usare MongoDB “perché è NoSQL” senza analizzare i dati. Un errore comune: modellare relazioni many-to-many embeddando array di ID, poi fare query lente su quei campi non indicizzati.
• Usare SQL con tabelle EAV solo per flessibilità. Fattibile ma diventa un inferno di performance e manutenibilità. Meglio MongoDB.
• Ignorare gli indici. Sia SQL che MongoDB ne hanno bisogno. In MongoDB gli indici composti sono fondamentali per l’aggregation pipeline.

In sintesi — cosa fare adesso

1. Analizza i tuoi dati reali: prendi un campione di dati e prova a modellarli in SQL e in MongoDB. Vedi quale schema è più naturale.
2. Stima le query più frequenti: per ognuna, valuta se in SQL serve un JOIN o in MongoDB un lookup. Fai un benchmark veloce.
3. Decidi in base al costo operativo totale: non solo licenze, ma ore di sviluppo, manutenzione, formazione.
4. Non ibridare il database a meno che sia necessario: avere sia SQL che MongoDB per lo stesso progetto aumenta la complessità. Se puoi, scegli uno e basta.
5. Contatta un team che ha già fatto queste scelte. Noi di Meteora Web lo facciamo ogni giorno. Se hai dubbi, parliamone.

E ricorda: un database non è una fede. Puoi cambiare idea. Ma farlo dopo aver scritto 50.000 righe di codice è doloroso. Scegli con criterio, non con l’hype.