SQL vs NoSQL: differenze reali e quando usare cosa

"SQL o NoSQL?" è una delle domande più frequenti quando si parte con un progetto, ed è anche una di quelle a cui si risponde peggio. In giro trovi articoli che ti dicono che NoSQL è "più moderno" e SQL "roba vecchia", oppure esattamente il contrario. Sono entrambe posizioni sbagliate. In questo articolo ti spiego cosa cambia davvero tra le due famiglie, e come si sceglie senza farsi guidare dalle mode.

SQL e NoSQL in parole semplici

SQL indica i database relazionali: i dati vivono in tabelle con colonne definite in anticipo, e le tabelle si collegano tra loro con delle relazioni. NoSQL è un'etichetta generica per tutti i database che non seguono questo modello: documenti, chiave-valore, grafi, vettori.

La prima cosa da chiarire è che "NoSQL" non è una tecnologia. È una categoria negativa — "tutto ciò che non è relazionale" — che mette nello stesso sacco strumenti profondamente diversi tra loro. MongoDB e Redis sono entrambi NoSQL, ma hanno pochissimo in comune.

Se non hai chiaro cosa sia un database in generale, parti da cos'è un database.

Come funziona un database SQL

In un database relazionale definisci prima la struttura: quali tabelle esistono, quali colonne hanno, di che tipo sono i dati e come le tabelle si collegano tra loro.

Un esempio classico, un e-commerce:

Tabella	Colonne
utenti	id, email, nome, data_registrazione
ordini	id, utente_id, totale, data
righe_ordine	id, ordine_id, prodotto_id, quantita

Ogni ordine punta a un utente tramite utente_id. Il database garantisce che quel riferimento sia valido: non puoi creare un ordine per un utente che non esiste. Questa si chiama integrità referenziale, ed è uno dei motivi per cui i relazionali sono ancora lo standard.

Il linguaggio per interrogarli è SQL:

SELECT u.nome, SUM(o.totale) AS speso
FROM utenti u
JOIN ordini o ON o.utente_id = u.id
WHERE o.data >= '2026-01-01'
GROUP BY u.nome
ORDER BY speso DESC;

Poche righe che uniscono due tabelle, aggregano e ordinano. Fare la stessa cosa a mano nel codice applicativo sarebbe molto più lungo e molto più lento.

I principali: PostgreSQL (vedi le novità di PostgreSQL 18), MySQL e MariaDB, SQLite, SQL Server.

Come funziona un database NoSQL

Qui bisogna distinguere, perché sotto l'etichetta ci stanno famiglie molto diverse.

Document store

I dati sono documenti, tipicamente in formato JSON. Ogni documento è autosufficiente e può avere una struttura diversa dagli altri.

{
  "_id": "u_1029",
  "email": "mario@esempio.it",
  "nome": "Mario",
  "ordini": [
    { "totale": 49.90, "data": "2026-03-02", "articoli": 2 }
  ]
}

Nota la differenza sostanziale: gli ordini stanno dentro l'utente, non in una tabella separata. Leggere il profilo completo è una singola operazione. Esempi: MongoDB, Firestore, CouchDB.

Chiave-valore

Il modello più semplice possibile: una chiave, un valore. Velocissimo, senza query complesse. Si usa soprattutto per cache e sessioni. Esempi: Redis, Valkey, DynamoDB.

Database a grafo

Ottimizzati per le relazioni tra entità: chi conosce chi, cosa porta a cosa. Rispondono in modo efficiente a domande come "trova tutti i contatti di secondo grado". Esempi: Neo4j, ArangoDB.

Vector database

La famiglia emersa con l'AI: memorizzano embedding e cercano per somiglianza semantica invece che per corrispondenza esatta. Ne parlo in dettaglio in cos'è un vector database.

Le differenze che contano davvero

Schema: rigido o flessibile

Il relazionale ti obbliga a decidere la struttura prima. Cambiarla dopo richiede una migrazione, e su tabelle grandi va pianificata.

Il document store ti lascia scrivere quello che vuoi. Sembra un vantaggio netto, ma c'è un rovescio della medaglia: lo schema non sparisce, si sposta nel codice applicativo. Dopo un anno di modifiche ti ritrovi con documenti di cinque generazioni diverse nella stessa collezione, e ogni funzione che li legge deve gestire tutti i casi. Il database non ti aiuta più a mantenere la coerenza: quel lavoro tocca interamente a te.

La flessibilità è reale, ma è un prestito, non un regalo.

Relazioni e join

I relazionali fanno i join in modo nativo ed efficiente. La maggior parte dei NoSQL no, o li fa male: devi denormalizzare, cioè duplicare i dati in più punti.

Duplicare significa che quando un dato cambia devi aggiornarlo ovunque sia finito. Se ne dimentichi un punto, hai dati incoerenti e il database non ti avvisa.

Regola pratica: se i tuoi dati sono pieni di relazioni, un relazionale ti farà risparmiare mesi di lavoro.

Consistenza e disponibilità

I relazionali offrono transazioni ACID: o un'operazione riesce interamente, o non succede nulla. Se sposti dei soldi da un conto a un altro, non può esistere un istante in cui i soldi sono spariti da uno senza essere arrivati all'altro.

Molti NoSQL distribuiti scelgono invece la consistenza eventuale: le repliche si allineano dopo un po'. Va benissimo per il contatore dei like di un post, molto meno per il saldo di un conto.

Se gestisci soldi, magazzino o qualsiasi cosa che debba tornare, servono transazioni serie. Oggi diversi NoSQL le supportano, ma con più limitazioni e più attenzione richiesta a chi scrive il codice.

Scalabilità

Questo è il punto su cui si dicono più imprecisioni.

Il NoSQL nasce per scalare orizzontalmente: aggiungi macchine e distribuisci i dati tra loro. È il motivo per cui è esploso nelle grandi piattaforme.

Ma va detto con chiarezza: PostgreSQL su una macchina decente regge un traffico che il 99% dei progetti non vedrà mai. Prima di scegliere un database "perché scala" conviene chiedersi se quel problema esista davvero. Nella stragrande maggioranza dei casi la risposta è no, e si finisce per pagare la complessità di un sistema distribuito per gestire diecimila utenti.

Tabella di confronto

Aspetto	SQL (relazionale)	NoSQL (document)
Schema	Definito in anticipo	Flessibile, ma gestito nel codice
Relazioni	Native, con join efficienti	Denormalizzazione manuale
Transazioni	ACID complete	Spesso limitate
Query complesse	Molto forti	Deboli o verbose
Scalabilità orizzontale	Più laboriosa	Progettata per farlo
Curva iniziale	Serve imparare SQL	Immediata all'inizio
Costo nel tempo	Basso	Cresce senza disciplina

Come scegliere davvero

Il mio consiglio, dopo aver visto parecchi progetti scegliere male in entrambe le direzioni:

Parti da un relazionale. PostgreSQL è la scelta di default sensata per la quasi totalità dei progetti: applicazioni web, gestionali, e-commerce, SaaS. Regge dati strutturati e semi-strutturati (supporta anche JSON nativo), scala molto più di quanto ti servirà, ed è pieno di documentazione.

Usa un document store quando i dati sono davvero eterogenei e con poche relazioni: cataloghi con attributi molto variabili, log di eventi, contenuti annidati che leggi sempre per intero.

Usa un chiave-valore come complemento, non come database principale: cache, sessioni, code di lavoro. Redis affiancato a PostgreSQL è una combinazione più che comune.

Usa un grafo solo se le relazioni sono il cuore del prodotto: social network, motori di raccomandazione, rilevamento frodi.

Usa un vector database se stai costruendo ricerca semantica o un sistema RAG — tenendo presente che PostgreSQL con l'estensione pgvector copre benissimo i progetti piccoli e medi, senza aggiungere un altro servizio da gestire.

Se vuoi un ragionamento più esteso sui singoli prodotti, ho scritto una guida dedicata: quale database scegliere.

Gli errori più comuni

L'errore che vedo più spesso non è scegliere "quello sbagliato": è scegliere in base a quello che usa una grande azienda. Netflix, Uber e Meta hanno problemi di scala che il tuo progetto non ha, team di infrastruttura dedicati e vincoli molto specifici. Copiare le loro scelte tecnologiche senza avere i loro problemi significa importare la complessità senza il beneficio.

Il secondo errore è più sottile: scegliere NoSQL per evitare di imparare SQL. SQL è uno dei linguaggi con il miglior rapporto tra tempo di apprendimento e utilità nell'arco di una carriera. È stabile da decenni, funziona ovunque e non passerà di moda. Evitarlo non è un risparmio, è un rinvio.

E in ogni caso: niente vieta di usarli insieme. Le architetture reali sono quasi sempre miste.

In sintesi

SQL e NoSQL non sono generazioni successive della stessa cosa: sono strumenti con priorità diverse. I relazionali privilegiano coerenza, relazioni e query espressive; i NoSQL privilegiano flessibilità e distribuzione, chiedendo in cambio più disciplina nel codice applicativo.

Per la stragrande maggioranza dei progetti la scelta di default è un database relazionale, con eventualmente un NoSQL affiancato per compiti specifici. Il criterio giusto non è quale sia più moderno, ma quale forma hanno i tuoi dati e quali garanzie ti servono davvero.

Se stai partendo con un progetto e vuoi impostare bene lo stack fin dall'inizio, la consulenza per nuovi progetti serve esattamente a evitare scelte che poi costano care.