--- term: 'Database NoSQL vs. SQL' seoTitle: 'NoSQL vs. SQL: differenze, miti e come scegliere' headline: 'Database NoSQL vs. SQL: quale, e quando?' slug: nosql-vs-sql category: database shortDefinition: 'Un database SQL è un archivio relazionale con tabelle fisse e join; NoSQL è una famiglia di modelli flessibili progettati per scalare in orizzontale.' relatedTerms: - relational-queries-document-databases - database-abstraction-layer - database-schema - acid-transactions contrastsWith: - relational-queries-document-databases aboutTerms: - 'SQL (Relational) Databases' - 'NoSQL Databases' faq: - question: 'Qual è la differenza principale fra SQL e NoSQL?' answer: 'Il modello dei dati e le sue conseguenze. I database SQL conservano i dati in tabelle collegate, con uno schema imposto in scrittura e un unico linguaggio di query standard; NoSQL è una famiglia che copre quattro modelli diversi – documentale, chiave-valore, a colonne larghe, a grafo – con schemi flessibili e API di query proprie di ogni database, progettati da subito per distribuirsi in orizzontale su più macchine.' - question: 'NoSQL è più veloce di SQL?' answer: 'Nessuno dei due è intrinsecamente più veloce – il mito sopravvive perché ciascuno vince in casa. I modelli NoSQL vincono su letture e scritture a volume elevato a forma di chiave, dove i dati sono conservati nel modo in cui vengono letti. I motori SQL vincono su join complessi, analisi ad hoc e transazioni su più righe. La velocità nasce dalla corrispondenza fra modello e pattern di accesso, non dall''etichetta.' - question: 'Quando conviene usare NoSQL invece di SQL?' answer: 'Quando i dati hanno la forma degli oggetti dell''applicazione e si leggono come un''unità (documentale), quando dominano il volume di scrittura e la scalabilità orizzontale (colonne larghe, chiave-valore), quando lo schema evolve davvero di settimana in settimana, oppure quando le relazioni sono esse stesse il carico di lavoro (grafo). Cataloghi prodotti, sessioni, flussi IoT, feed e backend di app mobile sono i terreni classici.' - question: 'Quando SQL è la scelta migliore?' answer: 'Dati strutturati e prevedibili con integrità rigorosa: transazioni su più righe (denaro, ordini, magazzino), query ad hoc complesse e reportistica fra entità, e domini in cui vincoli e chiavi esterne codificano vere regole di business. Più l''argomento dell''ecosistema – decenni di strumenti, integrazione con l''analisi dei dati e un ampio bacino di assunzione.' - question: 'Quali sono i quattro tipi di database NoSQL?' answer: 'I database documentali (record in stile JSON – il cavallo da tiro generalista), quelli chiave-valore (la ricerca più semplice e rapida – cache, sessioni), quelli a colonne larghe (throughput di scrittura enorme su cluster – telemetria, serie temporali) e quelli a grafo (le relazioni come dati di prima classe – reti sociali, raccomandazioni, rilevamento delle frodi). Ognuno risponde a una domanda diversa.' - question: 'I database NoSQL possono fare transazioni ACID?' answer: 'Sempre più sì, con la portata scritta nelle clausole in piccolo. I database documentali hanno sempre reso atomiche le scritture su un singolo documento – e le transazioni ACID su più documenti sono arrivate anni fa, al prezzo di un calo prestazionale. I motori SQL distribuiti attaccano dal lato opposto, offrendo ACID relazionale con scalabilità orizzontale in stile NoSQL. La vecchia linea netta è diventata un gradiente.' - question: 'NoSQL significa senza schema?' answer: 'No – significa che lo schema è flessibile e imposto più tardi. La struttura esiste sempre; i database documentali adottano per impostazione predefinita lo schema-on-read, in cui l''applicazione definisce le attese, e la maggior parte supporta la validazione quando serve imporlo in scrittura. Le piattaforme documentali gestite di solito deducono schemi tipizzati in automatico – flessibilità con struttura visibile.' - question: 'SQL e NoSQL stanno convergendo?' answer: 'Visibilmente. I motori relazionali hanno acquisito tipi di colonna JSON con indicizzazione – documenti dentro le tabelle. I database documentali hanno acquisito transazioni e validazione. L''SQL distribuito ha portato la scalabilità orizzontale al modello relazionale, e i motori multi-modello parlano più modelli insieme. La scelta si sta spostando sul singolo carico di lavoro invece che sulla fede – ed è anche il motivo per cui la persistenza poliglotta è lo stato finale normale.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'NoSQL (Wikipedia)' url: 'https://en.wikipedia.org/wiki/NoSQL' - name: 'PostgreSQL JSON types documentation' url: 'https://www.postgresql.org/docs/current/datatype-json.html' - name: 'CAP Twelve Years Later — Eric Brewer' url: 'https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/' - name: 'MongoDB transactions documentation' url: 'https://www.mongodb.com/docs/manual/core/transactions/' cta: title: 'Scegli il motore, tieni il backend' text: 'Back4app fa girare il tuo backend su un database documentale con vocabolario relazionale – Pointer, Relation, schemi tipizzati – dietro un solo SDK e API generate automaticamente. Modella con libertà, interroga in modo relazionale, e non cambiare piattaforma solo per cambiare idea.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-05' translationKey: nosql-vs-sql --- **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 | Domanda | Risposta | | --- | --- | | SQL | Tabelle, join, schema-on-write, ACID, un linguaggio standard | | NoSQL | Quattro modelli – documentale, chiave-valore, colonne larghe, grafo – nati per scalare in orizzontale | | La risposta onesta sulla velocità | Ciascuno vince in casa; decide la corrispondenza modello-carico di lavoro | | I miti | "Senza schema", "sempre più veloce", "nessuna transazione" – tutti superati | | La tendenza | Convergenza: JSON in SQL, ACID in NoSQL, SQL distribuito | ## Lo stesso record, nei due mondi ```sql -- 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%'; ``` ```javascript // 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:** ```javascript // 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 // 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 ``` **Swift:** ```swift // 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") } } ``` **Kotlin:** ```kotlin // 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 | Dimensione | SQL (relazionale) | NoSQL (famiglia) | | --- | --- | --- | | Modello dei dati | Tabelle, righe, chiavi esterne | Documenti, chiave-valore, colonne larghe, grafo | | Schema | Imposto in scrittura | Flessibile; in lettura per impostazione predefinita, validazione facoltativa | | Linguaggio di query | SQL, standardizzato | API e DSL proprie di ogni database | | Join | Di prima classe, ottimizzati | Limitati – conviene modellare per aggirarli | | Transazioni | ACID completo, su più righe | Atomiche sul singolo record; su più record dove supportate | | Riflesso di scalabilità | In verticale (macchina più grande), in orizzontale a costo di fatica | In orizzontale (più macchine), per progetto | | Postura sulla coerenza | Immediata | Regolabile – spesso eventual consistency (coerenza finale) per default | | Terreno naturale | Denaro, ordini, reportistica | Cataloghi, sessioni, feed, telemetria, grafi | ## I quattro tipi di database NoSQL ```mermaid flowchart TB accTitle: Le quattro famiglie di database NoSQL accDescr: NoSQL copre i database documentali per i record a forma di app, quelli chiave-valore per le ricerche rapide, quelli a colonne larghe per un throughput di scrittura enorme e quelli a grafo per i dati centrati sulle relazioni. N["NoSQL"] --> D["Documentale
record JSON a forma di app
→ il default generalista"] N --> K["Chiave-valore
una chiave, un blob, O(1)
→ cache, sessioni, flag"] N --> W["Colonne larghe
throughput di scrittura enorme, in cluster
→ telemetria, serie temporali"] N --> G["Grafo
archi come dati di prima classe
→ social, raccomandazioni, frodi"] ``` 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](https://www.mongodb.com/docs/manual/core/transactions/); 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](https://www.postgresql.org/docs/current/datatype-json.html) (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](https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/) 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 | Scegliere SQL quando… | Scegliere NoSQL quando… | | --- | --- | | Transazioni su più righe proteggono denaro o scorte | I record si leggono come unità a forma di app | | Query ad hoc e reportistica sono costanti | I pattern di accesso sono noti e a forma di chiave | | I vincoli codificano regole di business | La flessibilità dello schema accelera l'iterazione settimanale | | Il dominio è fatto di join fino in fondo | La scalabilità orizzontale in scrittura è il vincolo | | Gli analisti vivono dentro gli strumenti SQL | Il carico di lavoro rientra nel superpotere di una sola famiglia | 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](/glossary/it/modellazione-dei-dati/) 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](/glossary/it/modellazione-dei-dati/) 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.