Michael Stonebraker, inventore di Postgres®, ha presentato il suo database all’Università di Berkeley nel 1986. Quarant’anni dopo, Postgres è diventato una scelta leader per una generazione di progetti di intelligenza artificiale (AI), e Stonebraker è considerato uno dei maggiori scettici riguardo ai metodi attualmente impiegati nello sviluppo di questi progetti. In nuove puntate della serie AI & Data Horizons di EnterpriseDB (EDB), Stonebraker e Bruce Momjian, cofondatore del PostgreSQL Global Development Group, evidenziano l’importanza di sistemi che siano capaci di adattarsi senza rompersi e di comunità che non siano controllate da un’unica azienda.
Zero, non 80
Il primo punto di Stonebraker riguarda il text-to-SQL, l’aspettativa che un utente aziendale possa formulare una domanda in linguaggio naturale e ottenere una risposta dalla banca dati. Benchmarks pubblici come Spider e BIRD riportano un’accuratezza superiore all’80%. Tuttavia, il suo team ha provato la stessa cosa con il proprio data warehouse del MIT, composto da 1.400 tabelle contenenti informazioni su studenti, docenti, edifici e stipendi, utilizzando query reali dal log SQL.
“Abbiamo ottenuto un’accuratezza pari a zero. Non 80, non 70, non 40—zero,” ha dichiarato. Anche se successivamente l’integrazione di AI agentica, recupero e ingegneria dei prompt ha aumentato questa percentuale, l’accuratezza rimaneva nel range delle decine. “Non siamo ancora pronti per l’uso commerciale,” ha aggiunto.
Le difficoltà sono comuni in ogni azienda. Non esiste formazione adeguata, poiché il data warehouse non è accessibile su internet, e i dati sono particolari, ad esempio gli edifici del MIT non hanno nomi, ma solo numeri. Gli schemi sono deteriorati, con nomi di tabelle e colonne crittografati e viste sovrapposte. Inoltre, le query reali risultano più complesse di quelle sui benchmark. La sua squadra ha anche pubblicato un benchmark, Beaver, ma sostiene che nessuno ha superato un’accuratezza del 30%.
Usare il modello per ciò per cui è adatto
Stonebraker sottolinea anche un problema di architettura. I grandi modelli linguistici sono bravi con il testo, ma “non sono in grado di effettuare join di dati strutturati,” che costituiscono la maggior parte di ciò che detiene un’azienda. Lavorando con il dipartimento dei trasporti di Monaco, il team di Stonebraker ha scoperto che rispondere a un singolo reclamo da parte di un cittadino riguardo ai tempi di attraversamento delle strade richiedeva di combinare normative, disegni CAD, orari dei tram e mappe delle zone scolastiche. Coordinare tutto ciò con un modello linguistico centrale è risultato “assurdo in termini di costosità”.
La soluzione del team, un sistema chiamato Rubicon, usa modelli solo per il testo, poi trasforma i risultati in tabelle e passa il resto a un motore tabellare. L’orchestratore “assomiglia a un ottimizzatore di query.” Stonebraker afferma che questo approccio è più economico di un fattore 10 e notevolmente più preciso rispetto ai framework agentici basati su un modello.
Stonebraker prevede che l’AI agentica scivolerà dal picco dell’hype verso la valle della disperazione prima che emerga una visione più equilibrata. Le aziende odiano la non determinazione: approvare un prestito e poi annullarlo in fase di revisione è “un percorso verso una causa legale.” Le organizzazioni necessitano anche di protezioni contro agenti disguidati. I “guardrails” interni al database, nota, esistono in larga misura già: decenni di controllo degli accessi, log completi e trigger capaci di fermare una transazione sul nascere.
Nessuno lo possiede
Perché scegliere Postgres? “Postgres è la risposta intergalattica all’open source,” afferma Stonebraker. La sua caratteristica unica è che “non è controllato da alcuna azienda.” EDB, Microsoft, Google e altri contribuiscono ciascuno con i propri sviluppatori, e nessuno è al timone. Stonebraker colloca l’ascesa di Postgres all’acquisizione di MySQL da parte di Oracle, quando “tutti hanno detto: controllo del fornitore.” Per le aziende, questa indipendenza rappresenta le fondamenta della sovranità: mantenere il controllo su come e dove operano i loro sistemi informativi.
Momjian descrive la stessa struttura dall’interno. Postgres non ha un ufficio, beni né entità legale, eppure produce “software migliore di molte aziende miliardarie.” Il suo strumento di previsione è la comunità stessa, che identifica esigenze emergenti da Cina, Russia e Stati Uniti. “Ci vuole solo una persona estremamente intelligente nel mondo che ci dirà cosa pensa.”
Progettato per piegarsi
Entrambi gli esperti descrivono una filosofia di design che privilegia la flessibilità piuttosto che gli ultimi dettagli di velocità. Stonebraker ha progettato Postgres per essere estensibile, ed è per questo che ha assorbito JSON, ricerca full-text, GIS e ora AI senza alcun bisogno di riscrittura. Momjian aggiunge un secondo principio degli anni ’90: fare affidamento sul sistema operativo anziché assimilarlo, il che ha reso Postgres un’ottima scelta per il cloud.
Momjian critica le ottimizzazioni che offrono un guadagno del 5 o 10% a scapito della rigidità, poiché un sistema mal sintonizzato può perdere il 40%. “Se porti un’auto di Formula Uno al supermercato, non c’è posto per la spesa.” Il progetto guarda a un orizzonte che pochi venditori possono eguagliare. “Ci stiamo chiedendo quale sarà l’impatto tra 5, 10 anni.”
Cosa porta PostgreSQL 19
La nuova versione mette in mostra questa disciplina. Diverse funzionalità anticipate, comprese le query di grafi proprietari SQL e la fusione e divisione delle partizioni, sono state annullate, poiché la priorità è stata data alla stabilità. La revisione assistita dall’AI ha identificato rapidamente i problemi; la patch di agosto 2026 per PostgreSQL 18 ha affrontato 28 CVE.
Rimangono miglioramenti pratici: REPACK CONCURRENTLY per tabelle occupate, parallel autovacuum più intelligenti e sincronizzazione delle sequenze per la replica logica. Plan Advice, dal maggiore contributor di PostgreSQL e committer Robert Haas, è la risposta della comunità rispetto agli suggerimenti per l’ottimizzatore di stile Oracle, che sono stati rifiutati per anni. “Qualcuno ha trovato un modo per farlo che non presenta gli svantaggi,” afferma Momjian.
Il database come memoria dell’AI
I due esperti divergono su quanto velocemente l’AI scriverà SQL. Momjian si aspetta che agenti siano in grado di creare database e generare gran parte del codice. Stonebraker, al contrario, ritiene che ciò non avverrà all’interno delle aziende finché i dati non saranno documentati, i silos aperti e le politiche cambiate. Entrambi concordano sulla meta: l’AI necessità di un sistema relazionale per garantirne la permanenza e la memoria, e, come afferma Momjian, questo è “un cambiamento radicale.”
Quarant’anni dopo, l’inventore e il custode scommettono entrambi sullo stesso database.
Contributo di EnterpriseDB
