Tipi di database: Relazionali, Colonnari, Documentali, a Grafo e altro

Cosa significa davvero “tipo di database"

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).

Perché il “tipo” conta

Diversi tipi di database fanno diversi compromessi:

• Un database relazionale è ottimo quando i tuoi dati sono strutturati e ti servono transazioni affidabili.
• Un database colonnare brilla quando scansioni molte righe per rispondere a domande analitiche.
• Un database documentale può muoversi più velocemente quando la forma dei dati della tua app cambia spesso.
• Un database a grafo è costruito per dati con molte relazioni.
• Un database vettoriale si concentra sulla “similarità” più che sulle corrispondenze esatte.

Queste scelte progettuali influenzano:

• Pattern di query: molte piccole lookup, join complesse o grandi scansioni analitiche?
• Modello di scala: scala verso l'alto su una macchina potente o horizontalmente su molte macchine?
• Modello di dati: tabelle, documenti, coppie chiave-valore, grafi, vettori o punti temporizzati.

Cosa imparerai in questa guida

Questo articolo passa in rassegna i principali tipi di database e spiega, per ciascuno:

• In cosa eccelle (e dove fatica)
• Casi d'uso tipici nei prodotti reali
• I principali compromessi che influenzano prestazioni, costi e complessità

Una nota rapida sui sistemi “multi-model”

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.

Come usare questa guida per restringere le opzioni

Parti dal tuo carico principale:

• Se ti servono dati strutturati e transazioni, inizia da un database relazionale.
• Se fai reporting pesante e dashboard, considera un database colonnare o un data warehouse.
• Se la forma dei dati della tua app cambia spesso, prendi in considerazione un database documentale.
• Se ti servono lookup estremamente veloci per chiave, uno store chiave-valore è una forte opzione.

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.

Database relazionali (SQL): il default per i dati strutturati

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.

Perché SQL è ovunque

I sistemi relazionali si interrogano tipicamente con SQL (Structured Query Language). SQL è popolare perché è leggibile ed espressivo:

• Puoi filtrare e ordinare i dati (WHERE, ORDER BY).
• Combinare dati tra tabelle (JOIN).
• Riepilogare risultati (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à.

Transazioni ACID, in parole semplici

I database relazionali sono noti per le transazioni ACID, che aiutano a mantenere i dati corretti:

• Atomicità: una modifica multi-step è “tutto o niente”.
• Consistenza: le regole (come le foreign key) restano valide dopo le modifiche.
• Isolamento: aggiornamenti simultanei non si corrompono a vicenda.
• Durabilità: una volta salvati, i dati sopravvivono ai crash.

Questo è importante quando gli errori costano caro—come addebitare due volte un cliente o perdere un aggiornamento di inventario.

Workload più adatti

Un database relazionale è di solito la scelta giusta per dati strutturati e workflow ben definiti come:

• Applicazioni business (CRM/ERP)
• Finanza, pagamenti, fatturazione
• Inventario, ordini, prenotazioni

Insidie comuni da considerare

La stessa struttura che rende i relazionali affidabili può aggiungere attrito:

• Schema rigido: cambi frequenti nella forma dei dati possono richiedere migrazioni.
• Scaling con join pesanti: molti join su tabelle grandi possono diventare lenti o costosi a grande scala, soprattutto se i dati sono distribuiti su molte macchine.

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.

Database colonnari: costruiti per l'analisi

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.

Row-store vs column-store

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.

Perché il columnar è veloce per il reporting

Le query di analytics spesso:

• Scansionano molte righe
• Selezionano un piccolo set di colonne
• Calcolano aggregati come SUM, AVG, COUNT e raggruppano per dimensioni

Lo 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.

Pattern di query tipici

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.

Compromessi: aggiornamenti OLTP e lookup puntuali

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.

Dove eccelle

I database colonnari sono una buona scelta per:

• BI e cruscotti esecutivi
• Analytics su eventi e clickstream
• Reporting su log o transazioni su larga scala

Se la priorità sono aggregazioni veloci su grandi volumi di dati, il colonnare è spesso il primo tipo da valutare.

Database documentali: schemi flessibili per i dati di app

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.

Il modello documentale (record simili al JSON)

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.

Indicizzazione, a grandi linee

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.

Punti di forza e compromessi

I database documentali eccellono con schemi che evolvono, dati nidificati e payload pensati per API. I compromessi emergono quando hai bisogno di:

• Join complessi tra molte entità (spesso meno naturali rispetto a un relazionale)
• Transazioni multi-documento ad alta scala (supportate in molti prodotti, ma possono avere un costo prestazionale)
• Normalizzazione rigorosa (le squadre a volte duplicano dati per mantenere le letture semplici, il che richiede logiche di aggiornamento attenta)

Casi d'uso comuni

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”.

Store chiave-valore: lookup semplici e molto veloci

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.

Il modello chiave-valore (e perché è veloce)

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).

Perché sono popolari per caching e sessioni

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.

TTL, eviction e memoria vs disco

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).

Compromessi da considerare

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.

Casi d'uso comuni

Gli store chiave-valore sono ideali per:

• Rate limiting: contatori per utente/IP con finestra TTL
• Feature flags: letture veloci per decidere comportamenti per utente o coorte
• Carrelli della spesa: aggiornamenti rapidi a un oggetto carrello keyed per utente/sessione

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.

Database a colonne larghe (wide-column): storage operativo scalabile

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.

Wide-column vs analytics colonnare

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.

Dove eccellono

I sistemi wide-column sono progettati per:

• Alto throughput in scrittura (ingest di molti eventi al secondo)
• Scalabilità orizzontale (aggiungere nodi per gestire più traffico e dati)
• Letture a latenza prevedibile quando interroghi con la chiave giusta

Pattern di accesso tipico

Il pattern più comune è:

• Conosci la partition key (che decide dove i dati risiedono), e
• Leggi spesso un range all'interno di quella partizione (per esempio, “tutti gli eventi del device X tra 10:00–10:05”).

Questo li rende adatti per dati ordinati nel tempo e workload append-only.

Compromessi da comprendere

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.

Casi d'uso comuni

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.

Database a grafo: le relazioni come dati di prima classe

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.

Il modello grafo: nodi, archi e proprietà

Un grafo tipicamente ha:

• Nodi: le entità (persone, account, dispositivi, prodotti)
• Archi: le relazioni tra loro ("follows", "paid", "belongs to", "shipped to")
• Proprietà: attributi key-value su nodi e archi (timestamp, importi, etichette)

Questo rende naturale rappresentare reti, gerarchie e relazioni molti-a-molti senza forzare lo schema.

Perché i traversamenti possono battere i join

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.

Domande che i grafi risolvono bene

I grafi sono eccellenti per:

• Percorsi e gradi di separazione (percorso più corto, raggiungibilità)
• Raccomandazioni ("utenti che hanno comprato X hanno comprato anche Y", "amici di amici")
• Anelli di frode e pattern anomali (dispositivi, indirizzi e metodi di pagamento condivisi)

Compromessi da pianificare

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.

Quando un modello relazionale è ancora sufficiente

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.

Database vettoriali: ricerca per similarità per applicazioni AI

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.

Perché i vettori abilitano la ricerca semantica

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.

Operazioni core: similarità + filtri

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:

• Mostra solo documenti di un cliente specifico
• Limita a una categoria di prodotto o lingua
• Escludi elementi archiviati o di bassa qualità

Questo pattern “filtro + similarità” è come la ricerca vettoriale diventa pratica su dataset reali.

Dove si collocano i database vettoriali

Usi comuni includono:

• RAG (Retrieval-Augmented Generation): recuperare i passaggi più rilevanti prima che un LLM risponda
• Ricerca semantica: knowledge base, ticket di supporto o documentazione interna
• Raccomandazioni: “gli utenti che hanno visto X hanno anche visto Y” basate sulla similarità dei contenuti

Compromessi da conoscere

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).

Accoppiamento con relazionali o documentali

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.

Database per serie temporali: ottimizzati per metriche nel tempo

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.

Come sono fatti i dati time-series

La maggior parte dei record combina:

• Timestamp: quando è avvenuta la misurazione
• Metric/value: il numero che stai monitorando (latenza, temperatura, prezzo)
• Tag/label: metadata per filtrare e raggruppare (host=web-01, region=us-east, service=checkout)

Questa struttura semplifica domande come “mostra il tasso di errore per servizio” o “confronta la latenza tra regioni”.

Caratteristiche prestazionali su cui puntano i TSDB

Poiché il volume può crescere rapidamente, i TSDB si concentrano su:

• Compressione: memorizzare lunghe serie numeriche in modo efficiente
• Politiche di retention: eliminare automaticamente dati vecchi (es. raw 7 giorni, aggregati 90 giorni)
• Downsampling: aggregare i dettagli in sommari (per-secondo → per-minuto → per-ora)

Queste funzionalità mantengono costi di storage e query prevedibili senza pulizie manuali continue.

Pattern di query comuni

I TSDB eccellono quando hai bisogno di calcoli time-based, come:

• Medie mobili (es. media mobile a 5 minuti)
• Percentili (p95/p99 latency)
• Rate of change (richieste/secondo)
• Alerting su soglie o anomalie

Dove si adattano (e dove no)

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.

Data warehouse e lakehouse: analytics a livello aziendale

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.

Ingest batch vs streaming (versione semplice)

La maggior parte dei warehouse accetta dati in due modi comuni:

• Batch ingestion: i dati arrivano ogni ora/giorno (es. export notturni dal DB app). Più economico e semplice, ma non in tempo reale.
• Streaming ingestion: eventi che arrivano continuamente (click, pagamenti, IoT). I numeri sono più freschi, ma pipeline e monitoraggio diventano più importanti.

Perché sono veloci: columnar, partizionamento, materialized views

I warehouse sono ottimizzati per analytics con alcuni trucchi pratici:

• Storage colonnare legge solo le colonne necessarie per un report
• Partizionamento divide le tabelle per tempo o regione così le query scansionano meno dati
• Materialized views salvano risultati precomputati (es. “vendite giornaliere per paese”) per velocizzare i dashboard

La governance non è opzionale a scala

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.

Quando ha senso un lakehouse

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.

Compromessi chiave: consistenza, scala e pattern di query

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.

OLTP vs OLAP (abbina il workload)

Una regola rapida:

• OLTP (online transactions): molte piccole letture/scritture (checkout, login, aggiornamenti ordini). Priorità: bassa latenza, aggiornamenti corretti, molti utenti concorrenti.
• OLAP (analytics): meno query ma più pesanti che scansionano molte righe (dashboard, trend). Priorità: aggregazioni veloci, storage colonnare, separare compute da storage.

I relazionali spesso eccellono in OLTP; i sistemi colonnari, warehouse e lakehouse sono comuni per OLAP.

CAP in parole semplici

Quando una rete ha problemi, non puoi avere tutti e tre:

• Consistenza: tutti vedono gli stessi dati subito.
• Disponibilità: il sistema continua a rispondere.
• Tolleranza alle partizioni: continua a funzionare nonostante split di rete.

Molti DB distribuiti preferiscono rimanere disponibili e riconciliare dopo (consistenza eventuale). Altri privilegiano correttezza stretta, anche rifiutando richieste finché tutto non torna sano.

Scalabilità: verticale, orizzontale e sharding

• Scale-up verticale: macchina più potente—semplice, ma con limiti.
• Scale-out orizzontale: più macchine—più capacità, più coordinamento.
• Sharding: dividere i dati tra nodi (spesso per customer ID). Aumenta la scala, ma query e transazioni cross-shard diventano più difficili.

Transazioni e concorrenza in breve

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.

Preoccupazioni operative (non saltarle)

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.

Come scegliere il tipo di database giusto

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.

1) Parti dalle tue query (non dai dati)

Annota le 5–10 cose principali che la tua app o il tuo team devono fare:

• Cosa leggi più spesso (lookup singoli, filtri, join, aggregazioni, ricerca per similarità)?
• Cosa scrivi più spesso (insert di singole righe, stream di eventi, aggiornamenti, bulk load)?
• Quanto devono essere freschi i risultati (millisecondi, secondi, minuti)?

Questo restringe le opzioni più velocemente di qualsiasi checklist di feature.

2) Abbina il database alla forma dei tuoi dati

Usa questa checklist rapida:

• Campi strutturati e consistenti → database relazionale
• JSON semi-strutturato che cambia spesso → database documentale
• Molte relazioni molti-a-molti da percorrere → database a grafo
• Embedding e nearest-neighbor search → database vettoriale
• Eventi/metriche con timestamp e rollup → database per serie temporali
• Tabelle massive scale-out con accessi prevedibili → database a colonne larghe
• Semplice get/set per chiave → store chiave-valore
• Analisi pesante e scansioni → database colonnare (o warehouse)

3) Chiarisci latenza, throughput e driver di costo presto

Gli obiettivi di performance definiscono l'architettura. Imposta numeri approssimativi (p95 latency, letture/scritture al secondo, retention dei dati). Il costo solitamente segue:

• Storage (dati raw + repliche)
• Compute (query, ETL/ELT, job in background)
• Replica (multi-regione, HA)
• Indicizzazione (query più veloci, più overhead in scrittura)

4) Una semplice tabella decisionale

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.

Nota pratica se stai costruendo velocemente

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.