Database NoSQL vs. SQL: quale, e quando?

Un database SQL è un archivio relazionale con tabelle fisse e join; NoSQL è una famiglia di modelli flessibili progettati per scalare in orizzontale. Il dibattito è più vecchio di quanto meriti: la risposta onesta nel 2026 è che i due schieramenti hanno adottato i trucchi migliori l’uno dell’altro, e la vera competenza sta nell’abbinare ogni carico di lavoro al suo modello – a volte dentro una sola applicazione.

Punti chiave

Lo stesso record, nei due mondi

-- SQL: tabelle normalizzate, un join per leggere la coppia
CREATE TABLE products (
  id       bigserial PRIMARY KEY,
  name     text NOT NULL,
  brand_id bigint REFERENCES brands(id)
);

SELECT p.name, b.name AS brand
FROM   products p JOIN brands b ON b.id = p.brand_id
WHERE  p.name LIKE 'Espresso%';

// Modello documentale: il record nella forma in cui l'app lo legge
{
  "name": "Espresso Kit",
  "brand": { "name": "Nordic Roast" },       // incorporato – nessun join
  "badges": ["new", "staff-pick"],           // array, in modo nativo
  "warranty": { "months": 24 }
}
db.products.find({ name: /^Espresso/ })

Il lato flessibilità della storia, in diretta da un SDK – un campo nuovo parte insieme al salvataggio, senza cerimonie di migrazione, mentre la piattaforma tiene lo schema tipizzato e visibile:

// JavaScript / Node.js — Back4app JS SDK
// Document-model flexibility: the new field ships with the save
const product = new Parse.Object('Product');
product.set('name', 'Espresso Kit');
product.set('badges', ['new', 'staff-pick']);  // arrays are first-class
product.set('warranty', { months: 24 });       // nested objects too
await product.save(); // no migration ran; the column now exists, typed

// Flutter / Dart — Back4app Flutter SDK
// Document-model flexibility: the new field ships with the save
final product = ParseObject('Product')
  ..set('name', 'Espresso Kit')
  ..set('badges', ['new', 'staff-pick'])   // arrays are first-class
  ..set('warranty', {'months': 24});       // nested objects too
await product.save(); // no migration ran; the column now exists, typed

// iOS / Swift — Back4app Swift SDK
// Document-model flexibility with typed models on the client
var product = Product()
product.name = "Espresso Kit"
product.badges = ["new", "staff-pick"]     // arrays are first-class
product.warranty = ["months": 24]          // nested objects too
product.save { result in
  if case .success = result { print("saved — no migration ran") }
}

// Android / Kotlin — Back4app Android SDK
// Document-model flexibility: the new field ships with the save
val product = ParseObject("Product").apply {
  put("name", "Espresso Kit")
  put("badges", listOf("new", "staff-pick"))       // arrays are first-class
  put("warranty", JSONObject(mapOf("months" to 24))) // nested objects too
}
product.saveInBackground() // no migration ran; the column now exists

SQL vs. NoSQL sulle dimensioni che contano

I quattro tipi di database NoSQL

Euristiche da tenere a portata di mano: documentale quando i record si leggono come unità che l’app comprende (il modello dietro la maggior parte dei backend BaaS); chiave-valore quando la domanda è sempre “dammi la cosa che sta a questa chiave”; colonne larghe quando le scritture al secondo sono il numero in prima pagina; grafo quando sono le relazioni l’oggetto delle query.

I miti, in pensione

• “NoSQL significa senza schema.” Significa schema flessibile – struttura imposta in lettura per impostazione predefinita, in scrittura quando si attiva la validazione. Lo schema esiste sempre; la domanda è chi lo fa rispettare.
• “NoSQL è più veloce.” Errore di categoria: la lettura di un documento con i dati già uniti batte un join a cinque tabelle; un’aggregazione relazionale batte un map-reduce artigianale sui documenti. Decide il pattern di accesso.
• “NoSQL non sa fare transazioni.” L’ACID su più documenti è arrivato anni fa; l’unica verità durevole è che l’atomicità sul singolo record più una buona modellazione copre la maggior parte dei bisogni a costo minore.
• “SQL non scala in orizzontale.” I motori SQL distribuiti fanno esattamente questo, scambiando la latenza del consenso con garanzie relazionali su scala di cluster.
• “Bisogna scegliere uno solo.” La persistenza poliglotta – relazionale per gli ordini, documentale per il catalogo, chiave-valore per le sessioni – è l’architettura ordinaria dei sistemi maturi, non un’eccentricità.

La convergenza, in concreto

I due schieramenti si sono copiati i compiti: i motori relazionali hanno acquisito colonne JSON indicizzate (documenti dentro le tabelle), i database documentali hanno acquisito transazioni e validazione dello schema, e l’SQL distribuito ha consegnato il modello relazionale su scala orizzontale. Anche l’inquadramento del teorema CAP si è ammorbidito – la retrospettiva dello stesso Brewer insiste sul fatto che lo slogan “due su tre” semplifica all’eccesso: le partizioni sono rare, e i sistemi regolano la coerenza per singola operazione invece di scegliere un angolo per sempre. Il bilancio per il 2026: il confine SQL/NoSQL è un gradiente lungo il quale si posizionano i carichi di lavoro, non uno steccato dietro cui schierarsi.

Casi d’uso tipici

• SQL: elaborazione degli ordini e libri contabili, magazzino con invarianti, reportistica fra entità, tutto ciò che leggono i revisori.
• NoSQL documentale: backend di app (utenti, contenuti, cataloghi), prodotti mobile-first, MVP a iterazione rapida.
• NoSQL chiave-valore: sessioni, cache, feature flag, contatori per il rate limiting.
• NoSQL a colonne larghe: telemetria, flussi di eventi, serie temporali a ritmo da idrante.
• NoSQL a grafo: grafi sociali, raccomandazioni, reti di frode.
• Insieme: lo stack standard – spina dorsale relazionale per le transazioni, database documentale per i contenuti, cache chiave-valore davanti.

Conviene scegliere SQL o NoSQL? Matrice decisionale

E il criterio che rompe la parità per i backend di app in particolare: una piattaforma documentale gestita con vocabolario relazionale – schemi tipizzati, pointer, relation, transazioni dove servono – copre il centro di questa tabella, ed è il motivo per cui è diventata il default del BaaS.

Limiti e trade-off

• SQL: la cerimonia dello schema tassa l’iterazione; la scalabilità orizzontale si conquista, non è data; la frizione della mappatura oggetto-relazionale è permanente.
• NoSQL: i join non previsti in fase di modellazione fanno male; la eventual consistency sorprende chi non è preparato; quattro famiglie significano quattro insiemi di competenze.
• Entrambi: il modello sbagliato punisce su larga scala, e le migrazioni da un mondo all’altro sono progetti a sé – le decisioni di modellazione contano più del logo.
• La convergenza taglia da due parti: il JSON-dentro-SQL e l’ACID-dentro-NoSQL sfumano le indicazioni qui sopra – conviene misurare il proprio carico di lavoro, non il marketing.

SQL e NoSQL su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Occupa il punto di convergenza in modo deliberato: sotto un database documentale – flessibile, a forma di app, come nelle schede di codice qui sopra – e sopra un vocabolario relazionale: schemi tipizzati e visibili, Pointer e Relation per relazioni vere, join in una sola richiesta con include(), e operazioni atomiche dove la correttezza le pretende. Per la maggior parte dei backend di app quella via mediana chiude il dibattito: modellare come documenti, collegare come tabelle, e lasciare alla piattaforma la metà operativa di entrambe le scelte.