Relazionale, NoSQL, vettoriale o a grafo: quale usare?

Sono quattro famiglie nate per risolvere problemi diversi, non quattro concorrenti sullo stesso terreno. Il relazionale (PostgreSQL, MySQL, SQL Server) organizza i dati in tabelle con schema rigido e garantisce transazioni coerenti: è la scelta di default per tutto ciò che tocca soldi, ordini, inventari, dove perdere una riga o duplicarne un'altra è un incidente. Il NoSQL, sotto forma di documenti (MongoDB) o chiave-valore (Redis, DynamoDB), sposta il baricentro verso la scala orizzontale e lo schema flessibile: le transazioni ACID oggi ci sono quasi ovunque (MongoDB le supporta su più documenti dalla 4.0, DynamoDB dal 2018), ma restano più costose e di ambito più ristretto, e lo schema flessibile sposta i vincoli di coerenza dal database al codice applicativo. Il vettoriale indicizza embedding e risponde a query di somiglianza semantica, il motore dietro RAG e ricerca semantica. Il grafo modella nodi e relazioni esplicite, ottimo quando le query chiedono "chi è connesso a chi" più che "quanti sono".

Leggi anche: Vector database · Database che indicizza i dati per significato, non per parole esatte: la memoria su cui la RAG cerca i contenuti simili a una domanda.

Il default onesto

Molte aziende partono convinte di aver bisogno di tre o quattro database specializzati e finiscono per scoprire che PostgreSQL, con l'estensione pgvector, copre più terreno di quanto sembri: transazioni solide, JSON per dati semi-strutturati, e ricerca vettoriale nello stesso motore, senza sincronizzare sistemi separati. Non è la scelta giusta sempre, ma è quella da scartare per ultima: aggiungere un database specializzato ha un costo operativo reale, un altro sistema da monitorare, backuppare, mettere in sicurezza, e va giustificato da un problema che il default non risolve.

Quando serve davvero uno specializzato

Un database a grafo dedicato (Neo4j e simili) ha senso quando le query attraversano molti salti di relazione, tipico delle frodi o dei knowledge graph aziendali complessi. Un vettoriale dedicato (Pinecone, Weaviate, Milvus) ha senso a volumi di embedding molto alti o requisiti di latenza estremi che pgvector non copre più comodamente. In entrambi i casi il motore dedicato si aggiunge quando il default smette di reggere quei salti, quei volumi o quella latenza, non perché la sua famiglia è la più discussa del trimestre.