--- title: "Database NoSQL: cos’è e come funziona" url: https://www.conseolente.it/database-nosql-cosa-come-funziona/ aggiornato: 2026-10-28 descrizione: "Scopri cos'è un database NoSQL, come funziona e le differenze con i database relazionali SQL. Guida completa ai tipi e usi." topic: "Database NoSQL · esempi · database non relazionali" --- # Database NoSQL: cos’è e come funziona > Versione per assistenti AI. Pagina originale: [Database NoSQL: cos’è e come funziona](https://www.conseolente.it/database-nosql-cosa-come-funziona/?via=md) Un database NoSQL è un sistema di gestione dati “not only SQL” che archivia informazioni fuori dalle tabelle rigide dei database relazionali, usando documenti, coppie chiave-valore, colonne dinamiche o grafi. Questa impostazione consente schemi flessibili e scalabilità orizzontale su più server, al prezzo di una consistenza spesso eventuale anziché immediata. ## Database NoSQL in sintesi - **Struttura:** i dati non seguono righe e colonne fisse ma formati variabili come documenti JSON, coppie chiave-valore, colonne dinamiche o grafi. - **Tipi principali:** document database, key-value store, wide-column store e graph database coprono scenari diversi, dal catalogo e-commerce al social network. - **Scalabilità:** cresce orizzontalmente aggiungendo server al cluster, invece di potenziare una singola macchina come avviene nei sistemi relazionali. - **Consistenza:** gran parte dei database NoSQL applica il modello BASE con consistenza eventuale, mentre poche eccezioni come MongoDB offrono transazioni ACID. - **Confronto con SQL:** non sostituisce i database relazionali ma coesiste con essi in architetture ibride, dette a persistenza poliglotta. - **Diffusione:** il mercato dei database NoSQL vale 12,75 miliardi di dollari nel 2025 ed è in crescita costante a doppia cifra. ## Cos’è un database NoSQL e da dove nasce Un sistema di gestione dati non relazionale nasce per superare i limiti dei database basati su tabelle quando il volume e la varietà delle informazioni crescono rapidamente. L’espressione comparve per la prima volta nel 1998 come nome di un progetto relazionale leggero privo di interfaccia SQL, ma il significato attuale, “not only SQL”, si diffuse nel 2009 durante un incontro dedicato ai database distribuiti e open source organizzato a Last.fm. Prima della diffusione dei modelli relazionali, le organizzazioni si affidavano a sistemi gerarchici ad albero, complessi e vincolati a una singola applicazione. Il passaggio alle tabelle relazionali portò ordine, ma la rigidità dello schema divenne un ostacolo quando applicazioni come l’e-commerce e i social media richiesero strutture dati mutevoli e volumi enormi di traffico. L’alternativa non relazionale rispose a questa esigenza eliminando il vincolo delle tabelle collegate tra loro. La distinzione principale rispetto a un RDBMS (RDBMS) riguarda il modello dei dati: un database relazionale organizza le informazioni in righe e colonne fisse, mentre un sistema non relazionale usa un’unica struttura, come un documento o una coppia chiave-valore, priva di schema predefinito. Questo non rende un’opzione superiore all’altra: la scelta dipende dal tipo di dato, dal volume previsto e dal livello di coerenza richiesto dall’applicazione. ![Server collegati in un cluster distribuito che scambiano dati tra nodi](https://www.conseolente.it/wp-content/uploads/2026/10/database-nosql-cosa-come-funziona-1-1024x683.webp) La scalabilità orizzontale distribuisce il carico su più nodi invece di concentrarlo su un’unica macchina. ## Caratteristiche di un database NoSQL Quattro proprietà distinguono un sistema non relazionale da un database tradizionale: schema flessibile, scalabilità orizzontale, alte prestazioni in lettura e scrittura, architettura distribuita con tolleranza ai guasti. Lo schema flessibile permette di aggiungere o modificare campi senza una migrazione formale della struttura: ogni documento o riga può avere un numero diverso di attributi, utile quando i dati cambiano forma nel tempo. La scalabilità orizzontale, detta anche sharding, suddivide il carico di lavoro su più server quando una singola macchina non basta più, mentre un database relazionale scala solo verticalmente potenziando l’hardware esistente. Sul piano della coerenza dei dati, la maggior parte dei sistemi non relazionali adotta il modello BASE invece delle garanzie ACID tipiche dei database relazionali. Con la consistenza eventuale, gli aggiornamenti raggiungono tutti i nodi del cluster con un ritardo variabile, tipicamente entro millisecondi, generando in rari casi letture temporaneamente non aggiornate. Il teorema CAP formalizza questo compromesso: un sistema distribuito non può garantire simultaneamente consistenza, disponibilità e tolleranza di partizione, e deve scegliere quali due privilegiare. Alcuni prodotti, come MongoDB, offrono comunque transazioni ACID come funzione opzionale, dimostrando che la regola generale ammette eccezioni concrete. Il modello non relazionale utilizzato da Facebook per la funzione di ricerca nella posta in arrivo gestisce efficientemente oltre 100 milioni di utenti attivi in modo continuativo, a conferma della capacità di questi sistemi di reggere carichi su scala molto ampia, secondo [Access Control on NoSQL Databases](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8504.pdf). ![Quattro icone astratte che rappresentano documento, coppia chiave-valore, colonne e grafo di nodi collegati](https://www.conseolente.it/wp-content/uploads/2026/10/database-nosql-cosa-come-funziona-2-1024x683.webp) Document, key-value, wide-column e graph sono i quattro modelli dati principali dei sistemi non relazionali. ## Quali sono i quattro tipi principali di database NoSQL I sistemi non relazionali si dividono in quattro famiglie principali in base al modello con cui organizzano i dati: document database, key-value store, wide-column store e graph database. Ognuna risponde a esigenze applicative diverse e non è intercambiabile con le altre senza un costo in termini di prestazioni o complessità. ### Document database Un document database memorizza ogni elemento come un documento semi-strutturato in formato JSON, BSON o XML, con campi che possono variare da un documento all’altro. Ogni documento è un’unità autonoma identificata da una chiave univoca e raggruppata in collezioni analoghe alle tabelle relazionali, ma senza vincoli di schema condiviso. Questo modello è indicato per cataloghi prodotto con attributi variabili, profili utente e sistemi di gestione dei contenuti: una piattaforma CMS trae vantaggio dalla possibilità di gestire articoli con campi diversi senza modificare la struttura del database ogni volta. Prodotti come MongoDB e Couchbase rappresentano gli esempi più diffusi di questa categoria. È utile chiarire che JSON è un formato di serializzazione dei dati, non un linguaggio di programmazione: non va confuso con Python, che è invece un linguaggio usato anche per manipolare dati JSON, né sostituisce di per sé un database se non abbinato a un motore di interrogazione e indicizzazione. ### Key-value store Il modello a chiave-valore è il più semplice tra quelli non relazionali: ogni dato è una coppia composta da una chiave univoca e un valore associato, funzionando come una mappa hash. Questa semplicità garantisce latenze minime e throughput elevato, qualità richieste da sistemi di caching, gestione delle sessioni utente e classifiche in tempo reale. Un [sistema di cache degli oggetti](https://www.conseolente.it/object-cache-cosa-come-funziona/) si appoggia spesso proprio a un key-value store in memoria per velocizzare le letture ripetute. Redis e Amazon DynamoDB sono gli esempi più citati, il primo in-memory e orientato alla velocità, il secondo gestito e distribuito su scala cloud. ### Wide-column store e column family Un wide-column store organizza i dati in righe identificate da una chiave e raggruppa le colonne in famiglie di colonne, dette **column family**, anziché in tabelle rigide. Ogni riga può avere un numero diverso di colonne all’interno della stessa famiglia, il che rende questo modello adatto a serie temporali, log di eventi e dataset analitici di grandi dimensioni che cambiano struttura nel tempo. Apache Cassandra e Google Bigtable sono gli esempi di riferimento: il primo privilegia la scrittura intensiva e l’assenza di un singolo punto di guasto, il secondo è alla base di molti servizi di analytics su scala. ### Graph database Un graph database rappresenta i dati come nodi, che indicano le entità, e archi, che indicano le relazioni tra esse, con proprietà associate a entrambi. Questa struttura rende efficiente la navigazione di relazioni complesse e multilivello, impossibili da gestire con join relazionali su larga scala. Reti sociali, motori di raccomandazione e sistemi di rilevamento delle frodi sono i casi d’uso tipici. Neo4j è l’esempio più diffuso di questa categoria, seguito da Amazon Neptune per i workload cloud. ## Database SQL e NoSQL: le differenze principali Un database relazionale organizza i dati in tabelle fisse collegate da chiavi, con garanzie ACID e interrogazioni tramite SQL; un database non relazionale privilegia schemi dinamici e scalabilità orizzontale, spesso a scapito della consistenza immediata. Nessuno dei due modelli sostituisce l’altro: molte architetture li combinano nella stessa applicazione, pratica nota come persistenza poliglotta. | Caratteristica | Database SQL | Database NoSQL | | --- | --- | --- | | Struttura dei dati | Tabelle con righe e colonne fisse | Documenti, coppie chiave-valore, colonne dinamiche o grafi | | Schema | Predefinito e rigido | Dinamico, modificabile senza migrazione | | Scalabilità | Verticale, potenziando l’hardware di un singolo server | Orizzontale, aggiungendo nodi al cluster | | Consistenza | Forte, con transazioni ACID | Eventuale (BASE), salvo eccezioni come MongoDB | | Interrogazioni | Linguaggio SQL standard, join tra tabelle | Linguaggi specifici per prodotto, join limitati o assenti | Chi gestisce sistemi che interrogano i dati tramite [API](https://www.conseolente.it/api-application-programming-interface-cos-e-come-funziona/) applicative trova spesso nei database NoSQL un’integrazione più diretta con formati come JSON, già nativi per molte interfacce di programmazione web. ## Quando scegliere un database NoSQL e quando preferire SQL La scelta tra i due modelli dipende dal tipo di dato, dal volume previsto e dal livello di coerenza richiesto dall’applicazione, non da una presunta superiorità tecnica di un modello sull’altro. ### Se i dati sono non strutturati o cambiano spesso forma: usa un document o key-value store Quando i record hanno campi variabili, come profili utente con attributi opzionali o cataloghi con varianti di prodotto, uno schema flessibile evita migrazioni continue. Un document database o un key-value store assorbono queste variazioni senza bloccare le scritture. ### Se il traffico cresce rapidamente e serve scalare in orizzontale: usa un sistema distribuito nativo Quando il volume di letture e scritture supera la capacità di una singola macchina, aggiungere nodi a un cluster risulta più sostenibile che sostituire hardware. Wide-column store come Cassandra o key-value store gestiti come DynamoDB nascono per questo scenario. ### Se servono join complessi e transazioni finanziarie: preferisci un database relazionale Quando l’applicazione richiede di collegare più entità con vincoli di integrità referenziale e garanzie ACID complete, un database relazionale resta la scelta più solida: i database NoSQL supportano join limitati o assenti e richiedono di ridisegnare le interrogazioni per evitare costi di prestazioni. Per orientare la scelta del tipo specifico, è utile seguire un percorso in quattro passaggi: 1. Identificare la forma prevalente del dato: documenti variabili, coppie semplici, serie temporali o relazioni tra entità. 2. Stimare il volume di traffico previsto e la necessità di scalare oltre un singolo server. 3. Definire il livello di coerenza richiesto: se è indispensabile una consistenza forte, valutare un prodotto con supporto ACID o un modello ibrido con SQL. 4. Verificare la disponibilità di strumenti di query, backup e sicurezza nativi del prodotto scelto prima dell’adozione in produzione. ## Vantaggi e svantaggi di un database NoSQL I vantaggi principali riguardano flessibilità dello schema, scalabilità orizzontale e prestazioni elevate su grandi volumi; gli svantaggi riguardano la minore standardizzazione delle interrogazioni e i limiti sulla coerenza immediata dei dati. Tra i benefici concreti rientrano l’assenza di migrazioni di schema per aggiungere campi, il costo inferiore di scalare aggiungendo server rispetto a potenziare un’unica macchina, e tempi di risposta ridotti per operazioni di lettura e scrittura semplici su dataset enormi. Tra i limiti figurano l’assenza di un linguaggio di interrogazione standardizzato tra prodotti diversi, la difficoltà di eseguire join ad hoc tra insiemi di dati distinti e un investimento già consolidato in infrastrutture relazionali che rende meno immediata la migrazione. ### Errori frequenti nella scelta di un database NoSQL Un errore ricorrente consiste nell’adottare un modello non relazionale senza aver verificato se l’applicazione richiede transazioni complesse su più entità, finendo per ricostruire manualmente la logica di integrità che un database relazionale offrirebbe già. Un secondo errore è ignorare il modello di consistenza: progettare l’applicazione assumendo letture sempre aggiornate quando il prodotto scelto applica consistenza eventuale genera bug intermittenti difficili da riprodurre. Un terzo errore è trascurare la sicurezza nativa del prodotto: molti sistemi non relazionali richiedono una configurazione esplicita di autenticazione e cifratura, assente per impostazione predefinita in alcune installazioni, e restano esposti a tentativi di accesso non autorizzato come un [attacco brute force](https://www.conseolente.it/attacco-brute-force-cose-come-funziona-difendersi/) se le credenziali non vengono protette adeguatamente. ## Quali database NoSQL sono più diffusi Tra i prodotti non relazionali più adottati figurano MongoDB per i documenti, Redis per le coppie chiave-valore, Apache Cassandra per le colonne dinamiche, Neo4j per i grafi e Amazon DynamoDB come servizio gestito multi-modello su cloud. | Prodotto | Modello | Caso d’uso tipico | | --- | --- | --- | | MongoDB | Document | Cataloghi, CMS, profili utente | | Redis | Key-value (in-memory) | Caching, sessioni, classifiche | | Apache Cassandra | Wide-column | Serie temporali, log su larga scala | | Neo4j | Graph | Reti sociali, raccomandazioni, frodi | | Amazon DynamoDB | Key-value / document gestito | Workload serverless su AWS | Il mercato dei database NoSQL vale 12,75 miliardi di dollari nel 2025 e dovrebbe salire a 20,94 miliardi nel 2026, con un CAGR del 34,3% secondo [NoSQL Database Market Report 2026 (2025)](https://www.researchandmarkets.com/reports/6035527/nosql-database-market-report?srsltid=AU7gw4UQSabrb4QNXqRzVJ36kSArZ2GtAhIhy2PPfyLeVVKGA0CDNewH/). Le proiezioni di lungo periodo indicano un valore di 67,45 miliardi di dollari entro il 2030, con lo stesso CAGR del 34%, secondo [NoSQL Database Market Report 2026 (2030)](https://www.researchandmarkets.com/reports/6035527/nosql-database-market-report?srsltid=AU7gw4UQSabrb4QNXqRzVJ36kSArZ2GtAhIhy2PPfyLeVVKGA0CDNewH/), mentre altre stime collocano il mercato a 135,23 miliardi di dollari entro il 2034, con un CAGR del 30% tra il 2026 e il 2034, secondo [NoSQL Database Market: Industry Analysis & Forecast 2034 (2034)](https://www.maximizemarketresearch.com/market-report/global-nosql-database-market/97851/). Sul fronte dei prodotti, MongoDB detiene circa il 30% della quota del segmento non relazionale, seguito da Amazon DynamoDB con il 25% e Couchbase con il 20%, mentre il Nord America rappresenta circa il 38% della quota globale, secondo [Non-relational SQL Market Report: Creating Business … (2026)](https://www.linkedin.com/pulse/non-relational-sql-market-report-creating-business-vcfwf/). ## Domande frequenti sui database NoSQL ### Quali sono i quattro tipi principali di database NoSQL? I quattro tipi principali sono document database, key-value store, wide-column store e graph database. Ognuno organizza i dati in modo diverso e serve casi d’uso specifici, dai cataloghi prodotto alle reti sociali, senza che uno sostituisca completamente gli altri. ### Cos’è una column family in un database? Una column family è un raggruppamento di colonne correlate memorizzate insieme sul disco all’interno di un wide-column store. Ogni riga, identificata da una chiave, può avere un numero variabile di colonne all’interno della stessa famiglia, a differenza delle tabelle relazionali a struttura fissa. ### Netflix usa database NoSQL? Netflix utilizza sistemi non relazionali, tra cui Cassandra, per gestire workload distribuiti su scala globale che richiedono alta disponibilità e scrittura intensiva, affiancandoli ad altre tecnologie di persistenza in base al tipo di dato trattato. ### MongoDB è un database SQL o NoSQL? MongoDB è un database NoSQL di tipo document, che archivia i dati in formato BSON simile a JSON. Non utilizza tabelle relazionali né il linguaggio SQL come interfaccia principale, pur offrendo un proprio linguaggio di interrogazione e, in alcune versioni, transazioni ACID. ### JSON può essere usato come database? JSON è un formato di serializzazione dei dati, non un motore di database: può rappresentare i documenti memorizzati in un database NoSQL, ma da solo manca di indicizzazione, interrogazioni strutturate e gestione della concorrenza, funzioni fornite dal sistema di database che lo utilizza. ### DynamoDB è meglio di MongoDB? Nessuno dei due è superiore in assoluto: DynamoDB è un servizio gestito e serverless con prestazioni costanti a bassa latenza ma query limitate e legate all’ecosistema AWS, mentre MongoDB offre un modello documentale più flessibile e un linguaggio di interrogazione più ricco, a costo di una gestione dell’infrastruttura più diretta. ### Quali tipi di database NoSQL offre AWS? AWS mette a disposizione più modelli non relazionali: Amazon DynamoDB per il modello chiave-valore e documentale gestito, Amazon Neptune per i grafi, e supporto a soluzioni wide-column tramite servizi gestiti basati su Cassandra, ciascuno integrato nell’ecosistema cloud del provider. ### Come si protegge un database NoSQL? La sicurezza di un database non relazionale richiede autenticazione obbligatoria, cifratura dei dati in transito e a riposo, segmentazione di rete per limitare l’accesso ai nodi del cluster e monitoraggio costante degli accessi, poiché molte installazioni di default non attivano queste protezioni automaticamente. ## Fonti e riferimenti - [NoSQL Database Market Report 2026 (2026)](https://www.researchandmarkets.com/reports/6035527/nosql-database-market-report?srsltid=AU7gw4UQSabrb4QNXqRzVJ36kSArZ2GtAhIhy2PPfyLeVVKGA0CDNewH/) www.researchandmarkets.com - [NoSQL Database Market: Industry Analysis & Forecast 2034 (2034)](https://www.maximizemarketresearch.com/market-report/global-nosql-database-market/97851/) www.maximizemarketresearch.com - [Non-relational SQL Market Report: Creating Business …](https://www.linkedin.com/pulse/non-relational-sql-market-report-creating-business-vcfwf/) www.linkedin.com - [Access Control on NoSQL Databases](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8504.pdf) nvlpubs.nist.gov