Ogni revisione dell'architettura per un progetto di AI agentica si conclude con la stessa domanda: lo stack che già possediamo è in grado di supportare ciò che stiamo per costruire? La tentazione di rispondere a questa domanda è quella di confrontare le prestazioni dei database vettoriali. La domanda più profonda è se la tua architettura possa rispondere a domande su dati e significato nella stessa query, con le stesse garanzie.

Questo è ciò di cui un agente ha effettivamente bisogno. È la parte dello stack che la maggior parte dei team definisce per ultima, dopo che il resto del sistema ha già preso forma. Il database operativo viene dato per scontato. Secondo Harvard Business Review Analytic Services, solo il 15% delle organizzazioni ritiene che la propria infrastruttura dati sia pronta per l'AI agentica. Il risultato è un'architettura separata che sembra ragionevole su una lavagna e inizia a sfaldarsi in produzione.

I due modelli meritano un confronto onesto:

• Architettura unificata: un’unica piattaforma gestisce contemporaneamente i dati operativi e la ricerca vettoriale.
• Architettura separata: un archivio vettoriale dedicato (Pinecone, Weaviate o un motore di ricerca come Elasticsearch) opera in parallelo al database operativo, con una pipeline ETL che mantiene i due sistemi sincronizzati.

Analisi del ciclo virale della migrazione a Postgres

Ogni pochi mesi, un familiare post di blog diventa virale nell'ecosistema degli sviluppatori: "perché siamo tornati a Postgres". Quasi istantaneamente, le sezioni dei commenti si riempiono degli stessi prevedibili argomenti: MongoDB non scala, non ci sono unioni e le transazioni sono deboli. Tim Carter Clausen, che scrive come The Decipherist e gestisce MongoDB in produzione per un decennio, affronta direttamente ogni critica, con dati di produzione reali alle sue spalle.

La scelta di un database con un modello di dati compatibile con il resto dello stack garantisce che la velocità di sviluppo non sia ostacolata da vincoli architetturali.

Approfondimento: il costo della tassa sulla traduzione SQL

Una tipica richiesta SQL effettua otto modifiche di formato in un singolo giro di andata e ritorno:

1. Il cliente invia JSON.
2. L'API lo analizza in un oggetto JavaScript.
3. Uno strumento ORM decompone quell'oggetto in righe sparse su tabelle normalizzate.
4. Il database svolge il suo lavoro.
5. Le righe sono riassemblate.
6. Vengono mappate di nuovo in un oggetto.
7. L'oggetto viene serializzato nuovamente in JSON.
8. La risposta è stata inviata.

L'equivalente di MongoDB è quattro trasformazioni, e Clausen sostiene che chiamarle quattro esagerano perché la forma dei dati non cambia mai realmente. Ogni cambiamento di formato nel percorso SQL consuma CPU e memoria, introduce latenza e offre un luogo dove un bug può nascondersi.

La realtà degli aggiornamenti degli schemi

Rinominare un campo, aggiungere un oggetto nidificato o ristrutturare un documento: tutte queste operazioni avvengono in tempo reale in MongoDB, senza tempi di inattività. La stessa operazione contro una grande tabella relazionale può bloccare le scritture per minuti o addirittura ore. Per i team che effettuano spedizioni settimanali, la differenza non è teorica. È la differenza tra aggiungere un campo questo pomeriggio e programmare una finestra di manutenzione per il prossimo trimestre.

La tassa latente al layer di indicizzazione

La stessa divergenza architettonica si manifesta al layer di indicizzazione. Considera una query familiare a chiunque gestisca un sistema operativo: restituisci gli ultimi 10 ordini per un dato prodotto in un dato paese.

• Nel modello di documento: un singolo indice composto serve direttamente a questo, inclusi i campi annidati all'interno degli array.
• In un sistema relazionale (JSONB): l'equivalente richiede in genere un indice GIN per il contenuto della matrice, un indice B-tree separato per i campi scalari e un ordinamento pesante che il pianificatore di query non può evitare. Il piano legge più righe del necessario, e la scalabilità peggiora man mano che i dati crescono. Niente di tutto questo è visibile dal layer dell'applicazione, ma è tutto visibile sulla fattura del cloud.

Il potere strutturale della localizzazione dei dati

L'insight strutturale alla base di entrambi i punti è la localizzazione dei dati. Nel modello di documento, il modello logico e il modello fisico sono identici. La struttura che l'applicazione crea è esattamente la stessa che il database memorizza, e la struttura che il database memorizza è esattamente quella che il layer di recupero restituisce a un agente AI. Questa equivalenza elimina completamente le pipeline di sincronizzazione, la logica di doppia scrittura e i complessi processi di riconciliazione di cui le architetture frammentate avrebbero altrimenti bisogno per approssimare lo stesso risultato.

Il framework decisionale di un architetto

Il framework decisionale di Pachot si orienta verso queste realtà tecniche:

• Scegli relazionale (Postgres): per un database centralizzato che serve molte applicazioni diverse in cui i casi d'uso definitivi non sono ancora tutti noti.
• Scegli il documento (MongoDB): per un'applicazione singola realizzata a partire da un modello di dominio e salvata esattamente secondo la logica dell'applicazione stessa.

La domanda successiva da porsi è: quale di queste opzioni descrive meglio il lavoro del 2026? Microservizi con contesti delimitati, schemi che si aggiornano settimanalmente o oggetti di dominio persistenti nel modo in cui l'applicazione li concepisce naturalmente?

"Un database è buono e veloce se lo usi correttamente e la cosa più importante è sceglierne uno che conosci o che vuoi imparare."
— Franck Pachot, AWS Data Hero e Oracle Certified Master

Guarda la presentazione