Confronta i principali tipi di database—relazionali, colonnari, documentali, a grafo, vettoriali, chiave-valore e altri—con casi d'uso, compromessi e consigli per scegliere bene.
Un “tipo di database” non è solo un'etichetta: è un modo sintetico di descrivere come un sistema memorizza i dati, come li interroghi e per cosa è ottimizzato. La scelta influisce direttamente su velocità (cosa è veloce o lento), costo (hardware o cloud) e capacità (transazioni, analisi, ricerca, replica e altro).
Diversi tipi di database fanno diversi compromessi:
Queste scelte progettuali influenzano:
Questo articolo passa in rassegna i principali tipi di database e spiega, per ciascuno:
Molti prodotti moderni sfumano i confini. Alcuni database relazionali aggiungono supporto JSON che si sovrappone a un database documentale. Alcune piattaforme di ricerca e analytics offrono indicizzazione vettoriale come un vector database. Altri combinano streaming e storage con funzionalità da serie temporali.
Quindi “tipo” non è una scatola rigida—rimane però utile per capire i punti di forza predefiniti e i carichi di lavoro per cui un database è più adatto.
Parti dal tuo carico principale:
Poi usa la sezione “Come scegliere il tipo di database giusto” per restringere in base a scala, esigenze di consistenza e alle query che eseguirai più spesso.
I database relazionali sono ciò che molti immaginano quando si parla di “database”. I dati sono organizzati in tabelle composte da righe (record) e colonne (campi). Uno schema definisce l'aspetto di ogni tabella: quali colonne esistono, i loro tipi e come le tabelle si relazionano.
I sistemi relazionali si interrogano tipicamente con SQL (Structured Query Language). SQL è popolare perché è leggibile ed espressivo:
WHERE, ORDER BY).JOIN).GROUP BY).La maggior parte degli strumenti di reporting, le piattaforme di analytics e le app aziendali parlano SQL, perciò è una scelta sicura quando vuoi ampia compatibilità.
I database relazionali sono noti per le transazioni ACID, che aiutano a mantenere i dati corretti:
Questo è importante quando gli errori costano caro—come addebitare due volte un cliente o perdere un aggiornamento di inventario.
Un database relazionale è di solito la scelta giusta per dati strutturati e workflow ben definiti come:
La stessa struttura che rende i relazionali affidabili può aggiungere attrito:
Quando il modello dei dati cambia continuamente—o hai bisogno di una scalabilità orizzontale estrema con pattern di accesso più semplici—altri tipi di database possono essere più adatti.
I database colonnari memorizzano i dati “per colonna” invece che “per riga”. Questo singolo cambiamento ha grande impatto su velocità e costo per i workload analitici.
In una row-store tradizionale (comune nei relazionali), tutti i valori di un singolo record stanno insieme. Ottimo quando prendi o aggiorni frequentemente un cliente/ordine alla volta.
In un column-store, tutti i valori dello stesso campo stanno insieme—ogni price, ogni country, ogni timestamp. Questo rende efficiente leggere solo le poche colonne necessarie per un report, senza estrarre intere righe dal disco.
Le query di analytics spesso:
SUM, AVG, COUNT e raggruppano per dimensioniLo storage per colonne accelera questi pattern perché legge meno dati e comprime molto bene (valori simili clusterizzati si comprimono efficacemente). Molti engine colonnari usano anche esecuzione vettoriale e indicizzazione/partizionamento intelligente per velocizzare grandi scansioni.
I sistemi colonnari sono perfetti per dashboard e reporting: “fatturato per settimana”, “top 20 prodotti per regione”, “tasso di conversione per canale” o “errori per servizio negli ultimi 30 giorni”. Queste query toccano molte righe ma poche colonne.
Se il tuo workload è principalmente “recupera un record per ID” o “aggiorna una singola riga decine di volte al secondo”, il columnar può essere più lento o costoso. Le scritture sono spesso ottimizzate per batch (ingest append-only) piuttosto che aggiornamenti frequenti e piccoli.
I database colonnari sono una buona scelta per:
Se la priorità sono aggregazioni veloci su grandi volumi di dati, il colonnare è spesso il primo tipo da valutare.
I database documentali memorizzano i dati come “documenti”—record autonomi che assomigliano molto al JSON. Invece di dividere l'informazione su molte tabelle, di solito tieni insieme campi correlati in un unico oggetto (inclusi array nidificati e sotto-oggetti). Questo li rende naturali per i dati applicativi.
Un documento può rappresentare un utente, un prodotto o un articolo—completo di attributi che possono differire da un documento all'altro. Un prodotto può avere size e color, un altro dimensions e materials, senza forzare uno schema rigido per tutti.
Questa flessibilità è particolarmente utile quando i requisiti cambiano frequentemente o quando elementi diversi hanno set di campi diversi.
Per evitare di scansionare ogni documento, i documentali usano indici—strutture che aiutano a trovare rapidamente i documenti corrispondenti a una query. Puoi indicizzare campi di ricerca comuni (come email, sku, o status) e molti sistemi possono indicizzare anche campi nidificati (ad esempio address.city). Gli indici velocizzano le letture ma aggiungono overhead alle scritture, perché l'indice va aggiornato quando i documenti cambiano.
I database documentali eccellono con schemi che evolvono, dati nidificati e payload pensati per API. I compromessi emergono quando hai bisogno di:
Sono una scelta forte per content management, cataloghi di prodotto, profili utente e backend API—ovunque i dati si mappino naturalmente a “un oggetto per pagina/schermata/richiesta”.
Gli store chiave-valore sono il modello di database più semplice: memorizzi un valore (qualunque cosa, da una stringa a un blob JSON) e lo recuperi usando una chiave unica. L'operazione principale è praticamente “dammi il valore per questa chiave”, per questo questi sistemi possono essere estremamente veloci.
Poiché letture e scritture sono centrate su una singola chiave primaria, gli store chiave-valore possono essere ottimizzati per latenza bassa e throughput elevato. Molti sono progettati per tenere i dati caldi in memoria, ridurre la pianificazione di query complesse e scalare orizzontalmente.
Questa semplicità influenza anche come modellare i dati: invece di chiedere al DB “trova tutti gli utenti a Berlino che si sono registrati la settimana scorsa”, di solito progetti chiavi che puntano già esattamente al record voluto (per esempio user:1234:profile).
Gli store chiave-valore sono ampiamente usati come cache davanti a un database primario più lento (come un relazionale). Se la tua app richiede ripetutamente gli stessi dati—dettagli prodotto, permessi utente, regole di pricing—cachare il risultato per chiave evita di ricalcolare o rifare la query.
Sono anche naturali per lo storage delle sessioni (es. session:<id> -> session data) perché le sessioni vengono lette e aggiornate frequentemente e spesso scadono automaticamente.
La maggior parte degli store chiave-valore supporta un TTL (time to live) in modo che i dati scadano senza pulizia manuale—ideale per sessioni, token one-time e contatori di rate limit.
Quando la memoria è limitata, i sistemi usano politiche di eviction (come LRU) per rimuovere voci vecchie. Alcuni prodotti sono memory-first, altri persistono su disco per durabilità. Scegliere tra memoria e disco dipende se ottimizzi per velocità (memoria) o per conservazione/recupero (persistenza su disco).
Gli store chiave-valore sono ottimi quando conosci già la chiave. Sono meno adatti quando le domande sono aperte.
Molti hanno pattern di query limitati rispetto ai database SQL. Il supporto per indici secondari (query per campi dentro il valore) varia: alcuni lo forniscono, altri offrono opzioni parziali, altri incoraggiano a mantenere lookup keys aggiuntive.
Gli store chiave-valore sono ideali per:
Se il tuo pattern di accesso è “fetch/update per ID” e la latenza conta, uno store chiave-valore è spesso il modo più semplice per ottenere velocità affidabile.
I database wide-column (a volte chiamati wide-column store) organizzano i dati in famiglie di colonne. Invece di pensare a una tabella fissa con le stesse colonne per ogni riga, si raggruppano colonne correlate e si possono memorizzare set diversi di colonne per riga all'interno di una famiglia.
Nonostante il nome simile, i wide-column non sono la stessa cosa dei database colonnari per analytics.
Un database colonnare memorizza ogni colonna separatamente per scansionare dataset enormi in modo efficiente (ottimo per reporting). Un wide-column database è costruito per workload operativi su larga scala, dove serve scrivere e leggere molti record velocemente su molte macchine.
I sistemi wide-column sono progettati per:
Il pattern più comune è:
Questo li rende adatti per dati ordinati nel tempo e workload append-only.
Con i wide-column il data modeling è guidato dalle query: in genere progetti le tabelle intorno alle query esatte che devi eseguire. Questo può significare duplicare dati in forme diverse per supportare diversi pattern d'accesso.
Tendono anche ad offrire join limitati e meno opzioni di query ad-hoc rispetto a un relazionale. Se la tua app si basa su relazioni complesse e query flessibili, potresti sentirti limitato.
I wide-column sono spesso usati per IoT events, messaggistica e activity stream, e altri dati operativi su larga scala dove scritture veloci e letture prevedibili per chiave contano più di query relazionali ricche.
I database a grafo memorizzano i dati così come molti sistemi reali si comportano: come cose connesse ad altre cose. Invece di forzare le relazioni in tabelle e tabelle di join, le connessioni fanno parte del modello.
Un grafo tipicamente ha:
Questo rende naturale rappresentare reti, gerarchie e relazioni molti-a-molti senza forzare lo schema.
Le query con molte relazioni spesso richiedono molti join in un database relazionale. Ogni join aggiunge complessità e costo man mano che i dati crescono.
I database a grafo sono progettati per i traversamenti—camminare da un nodo ai nodi connessi, poi alle loro connessioni, e così via. Quando le tue domande sono del tipo “trova cose connesse entro 2–6 passaggi”, i traversamenti possono rimanere veloci e leggibili anche con l'espansione della rete.
I grafi sono eccellenti per:
I grafi possono richiedere un cambiamento per i team: la modellazione è diversa e i linguaggi di query (spesso Cypher, Gremlin o SPARQL) possono essere nuovi. Servono convenzioni chiare sui tipi di relazione e la direzione per mantenere il modello gestibile.
Se le relazioni sono semplici, le query sono per lo più filtraggio/aggregazioni e pochi join coprono le parti “connesse”, un database relazionale può rimanere la scelta più semplice—soprattutto quando transazioni e reporting già funzionano bene.
I database vettoriali sono progettati per un tipo specifico di domanda: “Quali elementi sono più simili a questo?” Invece di confrontare valori esatti (come un ID o una parola chiave), confrontano embedding—rappresentazioni numeriche di contenuti (testo, immagini, audio, prodotti) create da modelli AI. Elementi con significato simile tendono ad avere embedding vicini nello spazio multidimensionale.
Una ricerca tradizionale può perdere risultati se la parola usata è diversa ("laptop sleeve" vs. "notebook case"). Con gli embedding, la similarità è basata sul significato, così il sistema può riportare risultati rilevanti anche quando le parole non coincidono.
L'operazione principale è la nearest neighbor search: dato un vettore di query, recupera i vettori più vicini.
Nelle app reali, in genere combini la similarità con filtri, ad esempio:
Questo pattern “filtro + similarità” è come la ricerca vettoriale diventa pratica su dataset reali.
Usi comuni includono:
La ricerca vettoriale si basa su indici specialistici. Costruirli e aggiornarli può richiedere tempo e usare molta memoria. Spesso devi scegliere tra migliore recall (trovare più corrispondenze rilevanti) e minore latenza (risposte più veloci).
I database vettoriali raramente sostituiscono il tuo database principale. Un setup comune è: conserva il “source of truth” (ordini, utenti, documenti) in un database relazionale o documentale, memorizza embedding + indici di ricerca in un database vettoriale—poi unisci i risultati al DB primario per i record completi e i permessi.
I database per serie temporali (TSDB) sono progettati per dati che arrivano continuamente e sono sempre legati a un timestamp. Pensa a utilizzo CPU ogni 10 secondi, latenza API per ogni richiesta, letture sensoriali ogni minuto o prezzi azionari che cambiano più volte al secondo.
La maggior parte dei record combina:
Questa struttura semplifica domande come “mostra il tasso di errore per servizio” o “confronta la latenza tra regioni”.
Poiché il volume può crescere rapidamente, i TSDB si concentrano su:
Queste funzionalità mantengono costi di storage e query prevedibili senza pulizie manuali continue.
I TSDB eccellono quando hai bisogno di calcoli time-based, come:
Casi tipici: monitoring, observability, IoT/sensori e dati finanziari ad alta frequenza.
Il compromesso: i TSDB non sono l'ideale per relazioni complesse e query ad-hoc tra molte entità (ad esempio join profondi come “utenti → team → permessi → progetti”). Per quello, un relazionale o un grafo è solitamente più adatto.
Un data warehouse è meno un singolo “tipo di database” e più un workload + architettura: molte squadre che interrogano grandi dati storici per rispondere a domande di business (trend di fatturato, churn, rischio di inventario). Può essere un prodotto gestito, ma quello che lo definisce è come viene usato—centralizzato, analitico e condiviso.
La maggior parte dei warehouse accetta dati in due modi comuni:
I warehouse sono ottimizzati per analytics con alcuni trucchi pratici:
Quando più reparti si affidano agli stessi numeri, servono controlli di accesso, audit trail e lineage (da dove viene una metrica e come è stata trasformata). Spesso questo è importante quanto la velocità di query.
Un lakehouse fonde l'analitica da warehouse con la flessibilità di un data lake—utile quando vuoi un posto unico per tabelle curate e file raw (log, immagini, eventi semi-strutturati), senza duplicare tutto. È adatto quando il volume è alto, i formati variano e vuoi comunque reporting SQL-friendly.
Scegliere tra i tipi di database non è questione di “migliore” ma di adattamento: cosa devi interrogare, quanto velocemente e cosa succede se parti del sistema falliscono.
Una regola rapida:
I relazionali spesso eccellono in OLTP; i sistemi colonnari, warehouse e lakehouse sono comuni per OLAP.
Quando una rete ha problemi, non puoi avere tutti e tre:
Molti DB distribuiti preferiscono rimanere disponibili e riconciliare dopo (consistenza eventuale). Altri privilegiano correttezza stretta, anche rifiutando richieste finché tutto non torna sano.
Se molti utenti aggiornano gli stessi dati, servono regole chiare. Le transazioni raggruppano passi in “tutto o niente”. Lock e livelli di isolamento prevengono conflitti, ma possono ridurre il throughput; isolamenti più laschi aumentano la velocità ma possono introdurre anomalie.
Pianifica backup, repliche e disaster recovery presto. Considera quanto è facile testare restore, monitorare lag e fare upgrade—questi dettagli operativi spesso contano quanto la velocità di query.
Scegliere tra i principali tipi di database è più una questione di cosa devi fare con i dati che di cosa è alla moda. Un modo pratico per iniziare è lavorare a ritroso dalle tue query e dai tuoi workload.
Annota le 5–10 cose principali che la tua app o il tuo team devono fare:
Questo restringe le opzioni più velocemente di qualsiasi checklist di feature.
Usa questa checklist rapida:
Gli obiettivi di performance definiscono l'architettura. Imposta numeri approssimativi (p95 latency, letture/scritture al secondo, retention dei dati). Il costo solitamente segue:
| Primary use case | Best fit (spesso) | Perché |
|---|---|---|
| Transazioni, fatture, account utente | Relazionale (SQL) | Vincoli forti, join, consistenza |
| Dati app con campi in evoluzione | Documentale | Schema flessibile, naturale per JSON |
| Caching/session in tempo reale | Key-value store | Lookup veloci per chiave |
| Clickstream/metriche nel tempo | Time-series | Alto ingest + query time-based |
| Dashboard BI, grandi aggregazioni | Colonnare | Scansioni veloci + compressione |
| Relazioni sociali/knowledge | Grafo | Traversamenti di relazioni efficienti |
| Ricerca semantica, retrieval per RAG | Vettoriale | Ricerca per similarità su embedding |
| Dati operativi massivi | Wide-column | Scalabilità orizzontale, query prevedibili |
Molte squadre usano due database: uno per le operazioni (es. relazionale) e uno per analytics (es. colonnare/warehouse). La scelta giusta è quella che rende le tue query più importanti le più semplici, veloci e economiche da eseguire in modo affidabile.
Se stai prototipando o lanciando nuove funzionalità rapidamente, la scelta del database spesso si lega al flusso di sviluppo. Piattaforme come Koder.ai (una piattaforma vibe-coding che genera app web, backend e mobile da chat) possono rendere tutto più concreto: ad esempio, lo stack backend predefinito di Koder.ai usa Go + PostgreSQL, che è un ottimo punto di partenza quando ti serve correttezza transazionale e ampio tooling SQL.
Man mano che il prodotto cresce, puoi aggiungere database specializzati (un vector DB per la ricerca semantica o un warehouse colonnare per analytics) mantenendo PostgreSQL come sistema di record. L'importante è partire dai carichi che devi supportare oggi—e lasciare aperta la porta per “aggiungere un secondo store” quando i pattern di query lo richiedono.
Un “tipo di database” è un modo abbreviato per indicare tre cose:
Scegliere il tipo significa in pratica scegliere dei predefiniti per prestazioni, costi e complessità operativa.
Parti dalle tue top 5–10 query e pattern di scrittura, poi mappale sui punti di forza:
I database relazionali sono una solida scelta di default quando ti servono:
Diventano difficili quando cambi lo schema continuamente o quando ti serve una scalabilità orizzontale estrema con molte query join distribuite tra shard.
ACID è una garanzia di affidabilità per cambi multi-step:
Serve soprattutto per workflow in cui gli errori costano (pagamenti, prenotazioni, aggiornamenti di inventario).
I database colonnari sono ideali quando le query:
SUM, COUNT, AVG, )Un database documentale è adatto quando:
Attenzione però a join complessi, duplicazione dei dati per velocizzare le letture e al costo prestazionale delle transazioni multi-documento.
Usa uno store chiave-valore quando il tuo pattern di accesso è principalmente:
Pianifica intorno ai limiti: le query ad-hoc sono generalmente deboli e il supporto per indici secondari varia—spesso progetti chiavi aggiuntive per lookup.
Nonostante il nome simile, puntano a carichi diversi:
I sistemi wide-column richiedono spesso un modelling guidato dalle query (progettare tabelle intorno ai pattern d'accesso) e non offrono la stessa flessibilità dei join SQL.
Scegli un grafo quando le domande principali riguardano relazioni, ad esempio:
I grafi eccellono nei traversamenti (camminare tra nodi connessi) dove un approccio relazionale richiederebbe molti join. Il compromesso è adottare una modellazione differente e linguaggi di query (Cypher/Gremlin/SPARQL).
Un database vettoriale è pensato per la ricerca per similarità su embedding (rappresentazioni numeriche del significato). Viene usato per:
Nella pratica si affianca quasi sempre al DB principale: tieni il source-of-truth in un relazionale o documentale, conserva embedding e indici vettoriali nel vector DB e poi unisci i risultati per ottenere i record completi e rispettare i permessi.
Se fai sia OLTP che analytics, prevedi due sistemi fin da subito (DB operativo + DB analitico).
GROUP BYSono meno adatti a workload OLTP come aggiornamenti frequenti di singole righe o recuperi di un record singolo per ID, che le row-store gestiscono meglio.