Cos'è un graph database, e come differisce dal knowledge graph?

Un graph database è un motore di database che tratta nodi e relazioni come cittadini di prima classe, invece di simularli con tabelle e chiavi esterne come fa un database relazionale. Attraversare relazioni multi-livello (chi conosce chi, che dipende da cosa) è un'operazione nativa e veloce, non una serie di join costosi. Neo4j è il nome più noto della categoria, ma quasi ogni piattaforma dati oggi offre una capacità a grafo, nativa o come estensione. Internamente il modello a grafo si presenta di solito come property graph, nodi ed edge con etichette e coppie chiave-valore, o come triple RDF (soggetto, predicato, oggetto), nel qual caso il motore si chiama triplestore, con linguaggi di interrogazione dedicati (Cypher, Gremlin, SPARQL) pensati proprio per esprimere pattern relazionali che in SQL richiederebbero join annidati e poco leggibili. Su un dataset con milioni di connessioni, una query che chiede "trova tutti i percorsi a distanza tre da questo nodo" può girare in millisecondi su un graph database e in minuti, o non terminare affatto, su uno schema relazionale equivalente.

La distinzione da tenere ferma: tecnologia vs conoscenza

Il graph database è la tecnologia di storage: dove e come i dati a grafo vengono salvati e interrogati. Il knowledge graph è un livello sopra: la rete di entità e relazioni di business, definita da un'ontologia, che rappresenta la conoscenza dell'azienda. Un knowledge graph è spesso (ma non sempre) costruito sopra un graph database, ma il contrario non è vero: puoi avere un graph database pieno di dati senza alcun knowledge graph, se nessuno ha definito cosa quei nodi e quelle relazioni significano per il business. È lo stesso principio della differenza tra un database qualunque e i dati puliti e governati che lo rendono utile.

Quando ha senso adottarlo

Vince dove il valore sta nelle relazioni, non nei singoli record: rilevamento frodi (le reti di collegamenti sospetti), raccomandazioni, gestione di identità e permessi complessi, analisi di supply chain, ed è il substrato naturale della GraphRAG. Per la maggior parte dei problemi aziendali un database relazionale resta la scelta giusta; il graph database si giustifica quando le domande che fai ai dati sono ricorsivamente relazionali ("chi è connesso a chi, e quanto lontano"), non quando serve solo modellare qualche relazione occasionale.