SQL vs NoSQL: come scegliere nel 2021

Quando si progetta una nuova applicazione, una delle decisioni architetturali più importanti riguarda la scelta del database. SQL vs NoSQL è un dibattito che dura da circa vent’anni e che, nel 2021, è più attuale che mai: i dati sono cresciuti in volume, varietà e velocità, e le architetture moderne richiedono spesso più di un motore di persistenza.

In questa guida vediamo le differenze concrete tra database relazionali e NoSQL, le quattro categorie di NoSQL, le proprietà ACID e BASE, e soprattutto quando conviene scegliere l’uno o l’altro. L’obiettivo è darti un quadro pratico per la prossima decisione tecnologica, senza dogmi e senza hype.

1. SQL vs NoSQL: il dibattito che dura da 20 anni

I database relazionali nascono negli anni Settanta con il modello di Edgar F. Codd e dominano l’IT enterprise per oltre trent’anni: Oracle, IBM DB2, Microsoft SQL Server, MySQL e PostgreSQL sono cresciuti insieme ai gestionali, agli ERP e ai portali web. Tutto si modellava in tabelle con chiavi primarie e foreign key, e SQL era l’unico linguaggio di interrogazione dei dati.

Il termine “NoSQL” appare nel 2009 in un meetup di San Francisco organizzato da Johan Oskarsson. La spinta arriva dai grandi player del web (Google con Bigtable, Amazon con Dynamo, Facebook con Cassandra) che si trovano a gestire petabyte di dati distribuiti su migliaia di nodi: lo schema rigido del relazionale e i lock distribuiti diventano colli di bottiglia. Nascono così database progettati per scalare orizzontalmente, sacrificando alcune garanzie del modello relazionale.

Nel 2021 la dicotomia “SQL contro NoSQL” è ormai superata. Le aziende moderne usano entrambi i modelli: SQL per dati transazionali strutturati, NoSQL per cataloghi, sessioni, log, dati geospaziali e analitici. Il punto non è “qual è meglio” ma “qual è il giusto per questo caso d’uso”.

2. Database relazionali (SQL): caratteristiche e quando funzionano

Un database relazionale organizza i dati in tabelle composte da righe e colonne. Ogni tabella ha uno schema definito a priori (quali colonne, quali tipi, quali vincoli) e le tabelle sono collegate tra loro tramite chiavi esterne. Il linguaggio standard per interrogarle è SQL (Structured Query Language).

I motori SQL leader nel 2021 sono:

• MySQL 8: il più diffuso al mondo, usato da WordPress, Magento, milioni di applicazioni PHP. Open source, controllato da Oracle.
• PostgreSQL 13: il “relazionale plus” — supporta JSON nativo, full-text search, geospaziale (PostGIS), array, tipi custom. Oggi spesso preferito a MySQL nei nuovi progetti.
• MariaDB 10.5: fork di MySQL nato dopo l’acquisizione da parte di Oracle, mantenuto dai creatori originali.
• Microsoft SQL Server 2019: il riferimento in ambienti Windows enterprise, integrato con .NET e l’ecosistema Microsoft.
• Oracle Database 19c: ancora dominante in banche, telco e grandi enterprise per i carichi più critici.

I database relazionali brillano quando i dati sono strutturati e relazionati: anagrafiche clienti, ordini, fatture, contabilità, magazzino. La forza è la coerenza transazionale: o tutta la transazione va a buon fine, o nessuna parte. Un bonifico bancario, un movimento contabile, una conferma d’ordine non possono mai trovarsi in stato intermedio.

3. Database NoSQL: le 4 categorie principali

“NoSQL” è un’etichetta ombrello che raccoglie tecnologie molto diverse tra loro. La classificazione classica individua quattro categorie, ciascuna ottimizzata per un pattern di accesso ai dati specifico:

1. Document database: archiviano documenti JSON/BSON con struttura flessibile. Esempi: MongoDB, CouchDB, RavenDB.
2. Key-value store: tabelle hash distribuite, semplici e velocissime. Esempi: Redis, Memcached, Amazon DynamoDB, Riak.
3. Column store (o wide-column): tabelle con colonne dinamiche, ottimizzate per scritture massive. Esempi: Apache Cassandra, HBase, ScyllaDB.
4. Graph database: nodi e archi con proprietà, ottimizzati per query relazionali profonde. Esempi: Neo4j, ArangoDB, Amazon Neptune.

A queste si aggiungono i search engine come Elasticsearch 7 (tecnicamente document-oriented ma ottimizzato per ricerca full-text) e i time-series database come InfluxDB, ottimizzati per metriche e telemetria. Nel 2021, secondo il DB-Engines Ranking, MongoDB è il NoSQL più popolare seguito da Redis, Elasticsearch e Cassandra.

4. Document database (MongoDB, CouchDB)

I document database memorizzano i dati come documenti BSON o JSON, ciascuno con una struttura potenzialmente diversa. Niente schema rigido, niente tabelle, niente JOIN: un documento può contenere array, oggetti annidati, valori opzionali.

MongoDB 4.4 è il leader incontrastato di questa categoria. Tipico esempio: un catalogo prodotti e-commerce dove ogni articolo ha attributi diversi (un divano ha dimensioni e tessuto, uno smartphone ha CPU e RAM). In SQL servirebbero tante tabelle figlie o una tabella EAV ingombrante; in MongoDB ogni prodotto è un documento autocontenuto.

{
  "_id": ObjectId("60a..."),
  "sku": "DIV-001",
  "nome": "Divano Milano 3 posti",
  "prezzo": 899.00,
  "categoria": "Soggiorno",
  "attributi": {
    "tessuto": "tessuto sfoderabile",
    "colori": ["beige", "grigio", "blu"],
    "dimensioni": { "lunghezza": 220, "profondita": 95 }
  }
}

MongoDB scala orizzontalmente con lo sharding e dalla versione 4.0 supporta transazioni multi-documento (anche se a un costo prestazionale). È particolarmente adatto a CMS headless, cataloghi prodotti, profili utente con campi variabili, applicazioni mobile-first. Lo abbiamo usato in diversi progetti di web app e PWA dove i dati lato client sono naturalmente JSON.

CouchDB, sviluppato da Apache, è meno diffuso ma ha un punto di forza unico: la replica multi-master con risoluzione conflitti, ottima per applicazioni offline-first che si sincronizzano quando tornano online.

5. Key-value store (Redis, DynamoDB)

Il modello key-value è il più semplice: una mappa hash distribuita dove ogni chiave punta a un valore. Niente query complesse, niente JOIN, ma letture e scritture in microsecondi.

Redis 6 è probabilmente il database più amato dai developer: tiene tutti i dati in RAM (con persistenza opzionale su disco) e supporta strutture dati avanzate oltre alle stringhe — liste, set, hash, sorted set, stream, bitmap. Casi d’uso classici:

• Cache applicativa: alleggerire il carico sul DB principale memorizzando i risultati delle query più frequenti.
• Sessioni utente: storage rapido per i token di login, soprattutto in architetture stateless.
• Code di lavoro: con Redis Streams o Pub/Sub si implementano message broker leggeri.
• Rate limiting: contatori atomici per limitare le chiamate API per utente/minuto.
• Leaderboard e ranking: i sorted set sono perfetti per classifiche real-time.

Amazon DynamoDB è il key-value (più precisamente key-value/document) gestito di AWS: pensato per applicazioni con miliardi di record che richiedono latenze di pochi millisecondi a qualsiasi scala. Il prezzo si paga in flessibilità delle query: bisogna progettare le chiavi di partizione con attenzione, perché modificarle dopo è doloroso.

6. Column store (Cassandra, HBase)

I column store invertono la prospettiva: invece di memorizzare le righe in modo contiguo, memorizzano le colonne. Ogni “riga” (in realtà una partizione) può avere colonne diverse, e le colonne sono il vero “elemento atomico” di archiviazione.

Apache Cassandra 4 nasce in Facebook e oggi è gestita dalla Apache Software Foundation. La sua architettura è masterless: non esiste un nodo primario, tutti i nodi sono equivalenti, e il cluster sopravvive alla caduta di interi datacenter. È progettato per scritture massive e disponibilità elevatissima.

Casi d’uso tipici:

• Log e telemetria: miliardi di eventi al giorno scritti senza saturare il sistema.
• Time series IoT: misurazioni da sensori distribuiti che devono essere accumulate rapidamente.
• Dati di tracking: clickstream, eventi di gioco, telemetria di app mobile.
• Sistemi di messaggistica: WhatsApp, Discord e Netflix usano Cassandra in produzione.

HBase è la versione “Hadoop-native” del modello column store, modellata sul Bigtable di Google. È la scelta tipica quando si lavora già nell’ecosistema Hadoop/HDFS per analitica big data.

7. Graph database (Neo4j, ArangoDB)

I graph database modellano i dati come un vero e proprio grafo: nodi (entità) collegati da archi (relazioni), entrambi con proprietà. Sono la risposta giusta quando le relazioni tra entità sono importanti tanto quanto le entità stesse.

Provate a fare una query del tipo “trovami tutti gli amici degli amici dei miei amici che lavorano in aziende dove ho lavorato anch’io” su un database SQL: servono JOIN multipli, ricorsione, performance pessime. In Neo4j con il linguaggio Cypher è una query di poche righe che si esegue in millisecondi anche su grafi di milioni di nodi.

Casi d’uso classici per i graph database:

• Social network: amici, follower, gruppi, mention.
• Sistemi di raccomandazione: “chi ha comprato X ha comprato anche Y” attraversando connessioni multi-hop.
• Antifrode: identificare reti sospette di transazioni e identità collegate.
• Gestione della conoscenza: ontologie, knowledge graph, dipendenze tra concetti.
• Catena di approvvigionamento: tracciare componenti e fornitori a più livelli di profondità.

ArangoDB è interessante perché è multi-modello: supporta documenti, key-value e grafo nello stesso motore, riducendo la complessità di gestire più database.

8. ACID vs BASE: le proprietà dei database

Una delle distinzioni più importanti tra SQL e NoSQL riguarda le garanzie sulle transazioni. I database relazionali rispettano tradizionalmente le proprietà ACID:

• Atomicity: la transazione è “tutto o niente”.
• Consistency: dopo la transazione il database è in uno stato valido (vincoli rispettati).
• Isolation: transazioni concorrenti non si vedono tra loro.
• Durability: una volta committato, il dato non si perde anche in caso di crash.

Molti NoSQL, soprattutto quelli distribuiti, adottano invece il modello BASE:

• Basically Available: il sistema risponde sempre, anche se con dati non aggiornati.
• Soft state: lo stato del sistema può cambiare nel tempo senza input esterni (riconciliazione).
• Eventual consistency: dopo un certo tempo, tutti i nodi convergono allo stesso valore.

Il motivo di questa rinuncia è il teorema CAP di Eric Brewer: in un sistema distribuito non si possono garantire contemporaneamente Consistency, Availability e Partition tolerance. Bisogna sceglierne due. I database SQL classici scelgono CA (rinunciano alla scalabilità orizzontale), molti NoSQL scelgono AP (preferendo la disponibilità alla coerenza immediata).

Nel 2021 questa distinzione è meno netta: PostgreSQL ha cluster con replica logica, MongoDB supporta transazioni ACID, Cassandra ha “linearizable” su singola partizione. Ma il baricentro di ogni motore resta diverso, e va capito prima di scegliere.

Un esempio concreto del trade-off: in un sistema di prenotazione voli volete consistency stretta — non potete vendere lo stesso posto due volte, anche se questo significa che a volte un utente vede uno spinner di caricamento. In un social network, invece, preferite l’availability — è meglio mostrare un feed leggermente vecchio che un errore “servizio non disponibile”. Capire dove si colloca il vostro caso d’uso su questo asse è il primo passo della decisione architetturale.

Vale anche la pena ricordare che i moderni motori SQL come PostgreSQL hanno introdotto livelli di isolamento configurabili (Read Committed, Repeatable Read, Serializable) e tipi di replica diversi (sincrona, asincrona, logica). Anche all’interno di “ACID” ci sono molte sfumature, e capire i parametri di tuning del proprio database è spesso più importante della scelta del database stesso.

9. Quando scegliere SQL (i casi tipici)

Optate per un database relazionale quando si verifica una o più di queste condizioni:

1. I dati sono strutturati e stabili nel tempo. Un’anagrafica clienti, un piano dei conti, un magazzino con SKU codificati: lo schema cambia poco e quando cambia è un evento gestito.
2. Le relazioni sono molte e importanti. Un ERP gestisce ordini collegati a clienti, righe d’ordine a prodotti, prodotti a fornitori, movimenti contabili a partite IVA. SQL è nato per questo.
3. Servono transazioni multi-tabella ACID. Una vendita aggiorna magazzino, partitario, registro IVA, contabilità: o tutto o niente.
4. I report aggregati sono frequenti. SUM, GROUP BY, JOIN su milioni di righe sono il pane quotidiano di SQL e dei suoi indici.
5. Il volume non è “web scale”. Sotto le decine di TB e qualche migliaio di transazioni al secondo, un PostgreSQL ben configurato basta e avanza.
6. Il team conosce SQL. È un linguaggio diffusissimo, e l’ecosistema di tool (ORM, BI, backup, monitoring) è maturo da decenni.

I tipici gestionali personalizzati per PMI italiane — gestione produzione, magazzino, fatturazione, presenze — vengono ancora oggi quasi sempre costruiti su MySQL o PostgreSQL, con ottime ragioni.

10. Quando scegliere NoSQL (i casi tipici)

Considerate un NoSQL quando una o più di queste condizioni sono vere:

1. Schema variabile o evolutivo. Cataloghi prodotti con attributi diversi, profili utente con campi che cambiano spesso, dati provenienti da fonti eterogenee.
2. Volumi enormi e crescita rapida. Log, eventi, telemetria IoT, clickstream: parliamo di miliardi di righe scritte al giorno.
3. Latenza minima richiesta. Cache di sessione, leaderboard di gioco, autocomplete di ricerca: serve risposta in pochi millisecondi.
4. Distribuzione geografica. Un servizio mondiale che deve essere veloce su più continenti scala meglio con DynamoDB, Cassandra o Cosmos DB.
5. Modello del dominio nativamente JSON. API REST, frontend React, app mobile lavorano in JSON: passare da JSON a tabelle e viceversa è puro overhead.
6. Pattern di accesso “uno a molti” semplici. Recuperare il profilo dell’utente X, le ultime 50 notifiche, il carrello attivo: chiamate dirette per chiave, senza JOIN complessi.

Un’applicazione che gestisce contenuti generati dagli utenti, che si integra via integrazione API con servizi esterni e che deve scalare in cloud nasce spesso con un mix di Postgres + MongoDB + Redis. Le moderne soluzioni cloud rendono questo mix gestibile senza dover amministrare server.

11. Architetture polyglot persistence (uso ibrido)

Il termine polyglot persistence è stato coniato da Martin Fowler nel 2011 e descrive un’architettura dove ogni microservizio (o ogni tipo di dato) usa il database più adatto al proprio scopo. Nel 2021 è la norma nelle architetture moderne.

Esempio concreto di un’app e-commerce:

• PostgreSQL per ordini, fatture, anagrafica clienti, contabilità: serve ACID e relazioni forti.
• MongoDB per il catalogo prodotti con attributi variabili e contenuti CMS.
• Redis per il carrello attivo, le sessioni utente, il rate limiting delle API.
• Elasticsearch per la ricerca prodotti full-text con filtri faccettati.
• Neo4j per il motore di raccomandazione “chi ha comprato X ha comprato Y”.
• InfluxDB per le metriche di business (ordini/ora, conversioni, latenze).

Sembra complicato — e in parte lo è — ma ognuno di questi motori risolve un problema specifico molto meglio degli altri. Le architetture a microservizi rendono questa separazione naturale: ogni servizio è proprietario del suo database, e l’integrazione passa attraverso API o eventi.

Nei progetti di sviluppo software custom per PMI il polyglot persistence va dosato con attenzione: per una piccola realtà avere sei motori di database in produzione significa sei sistemi di backup, monitoring, aggiornamento, formazione del team. Spesso PostgreSQL + Redis è già un ottimo “polyglot light” che copre il 90% dei casi.

Una euristica pragmatica che usiamo nei nostri progetti:

• Fase 0-1 (MVP): un solo database. Quasi sempre PostgreSQL, perché copre relazionale, JSON, full-text, geospaziale. Aggiungere complessità quando non serve è il modo migliore per non arrivare in produzione.
• Fase 2 (crescita): aggiungete Redis quando le query iniziano a saturare il DB principale e vi servono sessioni o cache. È un’aggiunta a basso rischio.
• Fase 3 (scala): introducete il database giusto quando avete un problema misurato. Elasticsearch quando la ricerca SQL non basta, MongoDB quando avete dati con schema realmente variabile, una time-series db quando le metriche pesano sul DB transazionale.

L’errore opposto, cioè non introdurre mai NoSQL “perché tanto SQL basta”, è altrettanto comune. Un team che usa MySQL come cache di sessione, come coda di lavoro e come motore di ricerca full-text sta portando un cacciavite per piantare chiodi. Riconoscere il momento in cui il polyglot diventa necessario è una skill chiave del CTO.

Costi infrastrutturali a confronto

Spesso la scelta è anche economica. Considerando un carico medio di una PMI nel 2021 (qualche milione di record, qualche centinaio di transazioni al secondo), i costi mensili indicativi sono:

• PostgreSQL self-hosted su VPS 4 vCPU 16 GB: ~50-80 €/mese.
• MySQL su AWS RDS db.t3.medium con backup: ~80-120 €/mese.
• MongoDB Atlas M10: ~60 €/mese.
• Redis Cloud 250 MB: gratuito o ~5 €/mese; cluster reali da ~50 €/mese.
• Elasticsearch Service: parte da ~95 €/mese.

Aggiungere un secondo motore raddoppia i costi infrastrutturali e moltiplica la complessità operativa. Va fatto solo se la complessità ripagata è proporzionale.

Per approfondire ulteriormente, la voce dedicata su Wikipedia (NoSQL) offre un buon riepilogo storico e tassonomico delle famiglie di database non-relazionali.

12. Domande frequenti (FAQ)

NoSQL significa “no SQL” o “not only SQL”?
Originariamente “no SQL” (rifiuto del modello relazionale), poi rebrandizzato in “not only SQL” per indicare la coesistenza con i relazionali. Oggi molti NoSQL hanno un dialetto SQL-like (CQL di Cassandra, N1QL di Couchbase).

MongoDB sostituisce MySQL?
No. Sono progettati per scopi diversi. MongoDB brilla con dati semi-strutturati e schema flessibile; MySQL con dati transazionali strutturati. Spesso convivono nello stesso progetto.

Posso fare JOIN in MongoDB?
Dalla 3.2 esiste l’operatore $lookup in aggregazione, ma è meno performante dei JOIN SQL. La filosofia MongoDB è “modella i tuoi dati per come li interroghi”, quindi spesso si denormalizza embeddando documenti.

Quanto costa un database NoSQL gestito?
MongoDB Atlas parte da ~9 $/mese per cluster condiviso, AWS DynamoDB ha un free tier di 25 GB e modello pay-per-request, Redis Cloud parte gratuito fino a 30 MB. Per produzioni serie pianificate qualche centinaio di euro al mese minimo.

I database NoSQL sono “schema-less”?
Tecnicamente sì, ma in pratica uno schema c’è sempre — è solo gestito a livello applicativo invece che dal motore. Con MongoDB si usa spesso uno strato come Mongoose (Node.js) per validare la struttura.

Conviene migrare da SQL a NoSQL?
Solo se ci sono problemi concreti che SQL non risolve (volume, schema rigido, latenza, distribuzione globale). Migrare per “modernità” senza un caso d’uso reale è spesso un boomerang.