Cos'è un database multi-modello?

Un database multi-modello è un motore che immagazzina e interroga più modelli dati (relazionale, documentale, a grafo, chiave-valore, vettoriale) nello stesso prodotto, invece di affidare ciascun modello a un sistema specializzato separato. Il termine nasce a maggio 2012, coniato da Luca Garulli, creatore di OrientDB, in un keynote al NoSQL Matters di Colonia, come alternativa esplicita alla polyglot persistence: invece di più database specializzati collegati da pipeline di sincronizzazione, un solo prodotto ospita più modelli al proprio interno. Ma "gestire più modelli" è un'affermazione ambigua, e la survey accademica di riferimento, Lu e Holubová su ACM Computing Surveys (2019), distingue con precisione due capacità diverse: la capacità di storage (immagazzinare dati in più modelli nello stesso prodotto) e la capacità di garanzie cross-model (un'unica transazione, un unico ottimizzatore di query, una consistenza unificata su tutti i modelli). La stessa survey, analizzando i sistemi allora esistenti, non ne trova nessuno con vera gestione transazionale cross-model completa: quasi tutti offrono storage condiviso, pochi offrono garanzie realmente unificate.

Perché la distinzione conta

La differenza tra "immagazzina più modelli" e "garantisce una transazione unica su tutti i modelli" non è accademica: cambia cosa puoi promettere a un cliente interno. Se un'applicazione scrive un documento e aggiorna contemporaneamente un grafo di relazioni collegato, la domanda operativa è se quella scrittura è un'unica transazione atomica, con rollback coerente su entrambi i modelli in caso di errore, o se sono due scritture separate che condividono solo l'infrastruttura fisica sottostante, con due percorsi di fallimento indipendenti. DB-Engines ha formalizzato la distinzione nel 2019 introducendo i tag "primary model" e "secondary models" nel proprio ranking, segnale che il mercato aveva bisogno di un modo per dire "supporta più modelli" senza implicare automaticamente "le garanzie sono unificate".

La scelta enterprise reale

Un'azienda che deve tracciare ordini (relazionale), la rete di relazioni tra fornitori (grafo) e la ricerca semantica sui contratti (vettoriale) ha tre strade: sistemi specializzati separati con pipeline di sincronizzazione (polyglot persistence classica: più isolamento delle garanzie per modello, ma anche più sistemi da governare, latenza di sincronizzazione e superficie di guasto maggiori), oppure un data lakehouse con estensioni multi-modello, o un database nativamente multi-modello. Il vantaggio operativo di un solo prodotto è reale: meno sistemi da patchare, un solo modello di permessi, un team che impara un unico strumento. Il rischio è credere che "un prodotto solo" equivalga automaticamente a "una transazione sola": se il vendor offre storage condiviso ma ottimizzatori di query separati per modello, l'azienda ha comunque due sistemi di garanzie distinte, solo dentro lo stesso prodotto.

Le domande da fare prima di firmare

Chi valuta un database multi-modello dovrebbe verificare, con test concreti e non con la scheda marketing: una scrittura che tocca due modelli in una singola transazione fallisce e va in rollback su entrambi, o solo su uno? L'ottimizzatore di query pianifica join cross-model in un unico piano di esecuzione, o traduce internamente in query separate per modello? Il livello di isolamento delle transazioni (letture sporche, letture ripetibili) è identico su tutti i modelli, o varia da uno all'altro? Senza risposte verificate a queste tre domande, "multi-modello" descrive solo dove i byte vivono fisicamente, non cosa puoi promettere sull'atomicità delle operazioni che coinvolgono più modelli.