Polyglot persistence: perché le aziende usano 4-5 database

In sintesi. PostgreSQL per le transazioni, MongoDB per il catalogo, Redis per le sessioni, Neo4j per le relazioni, Elasticsearch per la ricerca: non è disordine, è architettura. Si chiama polyglot persistence e significa scegliere il database in base al modo in cui i dati vengono letti e scritti. In questo articolo vedi quando un solo database non basta più, come tenere sincronizzati più database senza corrompere i dati, come scegliere la consistenza per ogni dominio e cosa insegnano le architetture di Netflix, Uber e LinkedIn.

“Mettiamo tutto in PostgreSQL, per adesso funziona.” L’ho sentita in decine di riunioni di progetto, e quasi sempre è la decisione giusta per partire. Il problema è quel “per adesso”. Nasconde una crisi che arriva puntuale quando il sistema cresce: la tabella dei prodotti con 500 milioni di righe e campi JSONB i cui piani di esecuzione degradano; la ricerca testuale fatta con LIKE '%parola%' che scandisce l’intera tabella e non sa ordinare i risultati per rilevanza; le query sul grafo sociale scritte con self-join ricorsivi che diventano più lente a ogni livello di profondità; la gestione delle sessioni con una SELECT a ogni richiesta che esaurisce il pool di connessioni.

Nessuno di questi è un difetto di PostgreSQL. Sono tutti sintomi dello stesso errore di fondo: costringere dati con forme e modi d’uso diversi dentro un unico paradigma. Il deck che uso nel corso di Advanced Data Modeling al Politecnico di Torino lo riassume così: forzare tutti i dati in un solo modello significa ottimizzare per la comodità dello sviluppatore, non per le performance del sistema.

Questo articolo chiude la parte tecnica della serie Stack Digitale 2026. Nelle settimane scorse abbiamo visto uno per uno i mattoni — Neo4j, Kafka, InfluxDB, Airflow. Qui guardiamo il disegno d’insieme.

Lo strumento giusto per ogni lavoro

Ogni database è stato progettato intorno a un pattern di accesso specifico. Ignorare quel progetto ha un costo, e di solito lo paghi quando è più difficile cambiare. La tabella che segue è il punto di partenza di ogni discussione architetturale che faccio con studenti e clienti:

La definizione operativa è semplice: polyglot persistence significa scegliere, all’interno della stessa applicazione, la tecnologia di storage più adatta a ogni specifico pattern di accesso ai dati. Non si tratta di preferenze o di mode: si tratta di come i dati vengono letti.

“Ma PostgreSQL con JSONB non basta?”

È la domanda che gli studenti fanno ogni anno, ed è legittima. Il supporto JSONB di PostgreSQL è eccellente: indici GIN, operatori dedicati, query parziali sui documenti. Per molti progetti basta davvero. Smette di bastare quando i documenti arrivano a centinaia o migliaia di campi con uno schema che evolve in modo imprevedibile, quando serve sharding orizzontale su più nodi (possibile ma complesso in PostgreSQL), quando il volume di scrittura supera quello che un singolo nodo primario può assorbire, o quando ti serve un vero ranking di rilevanza e non la semplice presenza di una parola. La regola pratica: JSONB per qualche campo flessibile su dati strutturati; MongoDB quando il pattern di accesso principale è a documento. Se vuoi approfondire come si modella bene un database documentale, trovi una guida in due parti sui design pattern di MongoDB.

Data gravity: dove vivono i dati conta

C’è un concetto che spiega perché le decisioni sui database sono così difficili da cambiare: la data gravity. Applicazioni e servizi tendono ad accumularsi attorno ai dati, come i pianeti attorno a una massa. Spostare grandi dataset costa in banda, tempo e rischio di inconsistenza. La latenza cresce con la distanza fisica, dallo stesso rack alla stessa zona di disponibilità fino a un’altra regione. E ci sono vincoli normativi: il GDPR può imporre che certi dati restino nell’Unione Europea.

La conseguenza pratica è una regola che vale oro: decidi quale database è la fonte di verità per ogni dominio di dati prima di costruire, non quando hai petabyte da migrare. E tratta ogni database come proprietario di un dominio delimitato: i servizi non dovrebbero interrogare direttamente il database di un altro dominio, ma passare da API o eventi.

Il problema vero: tenere sincronizzati più database

Scegliere cinque database è la parte facile. Il difficile è tenerli coerenti tra loro. Quando un prodotto viene aggiornato in PostgreSQL, il suo documento in Elasticsearch deve riflettere la modifica; quando un utente segue un altro utente, il grafo Neo4j deve saperlo.

L’anti-pattern: la doppia scrittura

L’approccio ingenuo è scrivere in entrambi i database dalla stessa funzione:

# ANTI-PATTERN: dual write
def create_product(data):
    postgres_db.insert("products", data)        # passo 1
    elasticsearch.index("products", data)       # passo 2: e se fallisce?

Se il passo 1 riesce e il passo 2 fallisce, i due database divergono in silenzio. Non c’è atomicità tra due sistemi esterni, e la logica di retry tende a creare duplicati. Come dice una slide del corso: le doppie scritture senza un coordinatore portano alla corruzione eventuale, non alla consistenza eventuale.

La soluzione standard: Change Data Capture

Il Change Data Capture (CDC) ribalta la prospettiva. L’applicazione scrive in un solo database, la fonte di verità. Un processo separato legge il log delle transazioni di quel database e propaga ogni modifica agli altri sistemi. I vantaggi sono tre: disaccoppiamento completo (l’applicazione non sa nulla degli altri database), ordine garantito (il log riflette l’ordine reale dei commit) e possibilità di replay (un nuovo consumer può ricostruire il proprio stato da zero). La combinazione Debezium + Kafka è lo standard di produzione: Debezium legge il log di PostgreSQL, MySQL o MongoDB e pubblica ogni modifica su un topic Kafka, da cui i connettori sink la portano a destinazione. Ne abbiamo visto i dettagli nella seconda parte dedicata a Kafka.

Event sourcing, CQRS e Saga

Tre pattern completano la cassetta degli attrezzi, da usare con giudizio:

• Event sourcing: invece di salvare lo stato corrente, salvi ogni cambiamento come evento immutabile. Lo stato si ricostruisce rileggendo gli eventi, e ogni database diventa una “proiezione” ricostruibile in qualsiasi momento. In cambio ottieni un audit trail completo.
• CQRS (Command Query Responsibility Segregation): separi il modello di scrittura da quello di lettura. Ha senso quando il rapporto letture/scritture è molto sbilanciato (tipo 1000:1) e i due modelli richiedono schemi diversi. Aggiunge complessità significativa: non adottarlo se la scala non lo richiede davvero.
• Saga: la risposta alle transazioni distribuite. Invece di un commit a due fasi (2PC) su tutti i sistemi, spezzi la transazione in passi locali, ciascuno con la sua transazione di compensazione che lo annulla se un passo successivo fallisce.

Consistenza: una scelta per ogni dominio, non per tutto il sistema

Il teorema CAP ci dice che in un sistema distribuito, in presenza di partizioni di rete, bisogna scegliere tra consistenza e disponibilità. Nella pratica la scelta non è binaria: esiste uno spettro che va dalla linearizzabilità (tutti vedono lo stesso dato nello stesso istante) alla consistenza eventuale (prima o poi tutti vedranno lo stesso dato). E molti database permettono di regolarla operazione per operazione: in MongoDB con writeConcern e readPreference, in Cassandra con livelli come ONE o QUORUM.

La domanda giusta da porsi per ogni dominio è: gli utenti possono tollerare di vedere un dato non aggiornato? Per quanto tempo? Con quali conseguenze? Netflix è l’esempio perfetto. Per la riga “Continua a guardare” ha scelto la consistenza eventuale: se è indietro di qualche secondo, l’impatto sul business è quasi nullo e il guadagno in latenza è enorme. Per fatturazione e pagamenti usa MySQL con replica sincrona: consistenza forte, dove conta. La lezione: la consistenza non è una proprietà fissa del database, ma un parametro da scegliere per ogni tipo di dato in base al suo impatto.

Lambda, Kappa e Data Mesh

Quando i dati diventano tanti e arrivano in continuo, servono pattern architetturali di più alto livello. Lambda e Kappa li abbiamo confrontati nell’articolo su Kafka: Lambda affianca un livello batch (la verità definitiva) e un livello di velocità (il tempo reale), al prezzo di mantenere due pipeline; Kappa elimina il batch e ricalcola lo storico rileggendo il log, con una sola codebase.

Il Data Mesh, proposto da Zhamak Dehghani nel 2019, è diverso: non è una tecnologia ma un modello organizzativo. Si basa su quattro principi:

1. Proprietà decentralizzata per dominio: ogni team di dominio (vendite, logistica, marketing) possiede e gestisce i propri dati.
2. Dati come prodotto: con SLA, schemi versionati e documentazione, come qualsiasi prodotto interno.
3. Piattaforma self-service: il team centrale fornisce infrastruttura, non pipeline.
4. Governance federata: standard globali (schema registry, contratti sui dati) con autonomia locale.

Un avvertimento che do sempre: molte iniziative Data Mesh falliscono perché vengono trattate come progetti tecnologici. Richiedono prima un cambiamento organizzativo. Per una PMI con un solo team tecnico, il Data Mesh è quasi sempre fuori scala.

Tre casi reali: Netflix, Uber e LinkedIn

Le architetture delle grandi aziende tech non vanno copiate, ma studiate. Mostrano quali problemi emergono alla scala estrema e quali soluzioni hanno retto nel tempo. Le informazioni che seguono provengono dai blog di ingegneria delle tre aziende.

Netflix: un database per ogni esigenza

Con oltre 300 milioni di abbonati in più di 190 paesi, Netflix è l’esempio da manuale di polyglot persistence. MySQL gestisce fatturazione e abbonamenti, dove servono ACID e consistenza forte. Apache Cassandra è lo store più strategico: contiene la cronologia di visione e i profili, con un rapporto scritture/letture di circa 9 a 1 — esattamente il carico per cui Cassandra è ottimizzata, grazie alla replica senza leader e senza single point of failure. Elasticsearch alimenta ricerca, supporto clienti e analisi dei log. EVCache, un layer di cache costruito su Memcached e replicato in tutte le regioni AWS, serve dati di sessione e personalizzazione con tassi di hit altissimi. Apache Iceberg su S3 ospita i dati per analytics e machine learning. E Kafka collega tutto, con centinaia di miliardi di eventi al giorno.

Uber: creatività sotto pressione

I dati delle corse di Uber sono insieme simili a serie temporali, pesanti in scrittura, indicizzati geograficamente e necessari ovunque nel mondo con bassa latenza. La soluzione più interessante è Schemaless: nel 2014 i database documentali disponibili non soddisfacevano i requisiti di affidabilità di Uber, così il team ha costruito uno strato di sharding sopra MySQL, usandolo di fatto come document store. La lezione è profonda: “NoSQL” è un pattern di progettazione, non solo una categoria di prodotti. Per l’indicizzazione geografica Uber ha creato e rilasciato come open source H3, una griglia esagonale gerarchica: gli esagoni hanno la proprietà che tutti i vicini sono equidistanti dal centro, perfetta per trovare “gli autisti vicino a me” e calcolare le tariffe dinamiche per zona. Completano il quadro Kafka come dorsale, Hadoop per il data lake e Flink con Apache Pinot per l’analisi in tempo reale.

LinkedIn: gli strumenti che sono diventati standard

LinkedIn è notevole per quanti strumenti ha inventato e poi donato alla comunità. Kafka nasce lì nel 2010: il problema erano decine di pipeline ETL punto-a-punto tra sistemi interni, e ogni nuovo consumatore di dati ne richiedeva un’altra. L’intuizione di Jay Kreps fu che un log di commit durevole, ordinato e distribuito, a cui ogni consumatore si iscrive, poteva sostituirle tutte. Oggi LinkedIn gestisce migliaia di miliardi di messaggi al giorno su migliaia di broker. Accanto a Kafka ci sono Espresso, il document store interno per profili e messaggi (costruito su MySQL, con Kafka come trasporto di replica), Pinot per l’OLAP in tempo reale che alimenta “Chi ha visto il tuo profilo”, e Brooklin per il CDC tra store eterogenei.

I pattern comuni

Cosa evitano tutti e tre

Gli anti-pattern rifiutati sono istruttivi quanto le scelte fatte:

• Nessuno usa un solo database per tutto.
• Nessuno usa il commit a due fasi distribuito su larga scala. Lo sostituiscono Saga, transazioni di compensazione e consistenza eventuale.
• Nessuno fa doppie scritture sincrone. Il CDC dal log delle transazioni è lo standard.
• Nessuno applica la stessa consistenza ovunque. Fatturazione forte, feed eventuale, cache best-effort.

E soprattutto: queste architetture si sono evolute in anni. Partire semplici e crescere verso il polyglot è l’approccio corretto. Progettare cinque database dal primo giorno è una trappola.

E per una PMI? Un’architettura proporzionata

Qui arriva la parte che conta per la maggior parte di chi legge. Una PMI non è Netflix, e non deve provare a esserlo. Il percorso che consiglio ai clienti è incrementale:

1. Fase 1 — un database relazionale solido. PostgreSQL copre transazioni, dati strutturati, un po’ di JSONB, perfino dati geografici con PostGIS. Per molte aziende è la fase definitiva, e va benissimo così.
2. Fase 2 — il primo specialista. Si aggiunge quando compare un segnale preciso: la ricerca nel catalogo è lenta o imprecisa (Elasticsearch), le sessioni appesantiscono il database (Redis), i sensori generano milioni di righe (InfluxDB), le relazioni tra entità diventano il cuore delle domande (Neo4j). La sincronizzazione, a questa scala, può essere un job notturno orchestrato.
3. Fase 3 — la dorsale di eventi. Solo quando i database specializzati diventano tre o più e devono restare allineati in tempo quasi reale, conviene introdurre Kafka e il CDC.

Checklist prima di aggiungere un database

• Qual è il pattern di accesso che il database attuale non serve bene? Riesco a misurarlo?
• Quale database sarà la fonte di verità per questo dominio?
• Come si sincronizzeranno i dati: batch notturno, CDC, eventi applicativi?
• Quanto dato non aggiornato posso tollerare, e per quanto tempo?
• Chi nel team saprà gestirlo, monitorarlo e fare il backup?
• Cosa succede agli utenti se questo database va giù?

L’ultima domanda nasconde un vantaggio spesso sottovalutato: un’architettura polyglot ben progettata migliora l’isolamento dei guasti. Se Elasticsearch si ferma, la ricerca è temporaneamente non disponibile, ma gli ordini continuano a funzionare. Con un database unico, un guasto ferma tutto.

La mappa completa della serie

Adesso i pezzi della serie Stack Digitale 2026 si incastrano: ogni tecnologia che abbiamo visto ha un posto preciso nella mappa. Neo4j per le relazioni, Kafka per trasportare eventi e sincronizzare con il CDC, InfluxDB per le serie temporali, Airflow per orchestrare i processi batch, Grafana per rendere tutto visibile. La polyglot persistence non è una tecnologia in più: è il criterio che ti dice quale usare, quando e perché.

Se il tuo sistema attuale mostra qualcuno dei sintomi descritti all’inizio — query sempre più lente, ricerca che non trova, dati duplicati tra sistemi che non si parlano — richiedi un audit dati e AI. Analizziamo i tuoi pattern di accesso reali e costruiamo una roadmap proporzionata: a volte la risposta è un nuovo database, spesso è usare meglio quello che hai già.