La prossima versione principale di PostgreSQL è prevista per il 19 novembre 2026, dopo una fase di beta più impegnativa del previsto. Tra i fattori che hanno contribuito al ritardo c’è l’aumento dei difetti individuati con strumenti di revisione assistiti da modelli linguistici: trovarli è diventato più rapido, ma verificarli e correggerli richiede ancora tempo e lavoro umano.
La precisazione è importante: non si tratta semplicemente di una valanga di codice scritto dall’intelligenza artificiale e inviato al progetto. Secondo le ricostruzioni disponibili, gli strumenti hanno aiutato a esaminare codice già esistente e a portare alla luce problemi, anche in casi limite, che altrimenti avrebbero potuto emergere più lentamente.
Trovare un bug non equivale a risolverlo
Un rapporto prodotto da uno strumento automatico non è una correzione pronta da integrare. I manutentori devono capire se il problema è reale, riprodurlo, valutarne la gravità e stabilire quale modifica sia sicura. Poi devono testare la soluzione e controllare che non introduca regressioni.
Nel caso di PostgreSQL, il carico è stato aggravato dal numero di segnalazioni e dal lavoro necessario a gestire correzioni e problemi nelle versioni già supportate. Peter Eisentraut, sviluppatore e committer del progetto, ha descritto un accumulo di segnalazioni di difetti assistite dall’uso di LLM; ha anche osservato che le correzioni proposte automaticamente non sono sempre corrette o conformi agli standard del progetto e richiedono revisione umana.
È qui che emerge il paradosso: un sistema può rendere più efficiente la ricerca dei problemi e, allo stesso tempo, aumentare il lavoro complessivo. Il collo di bottiglia non è più soltanto individuare i difetti, ma avere abbastanza persone con il tempo e le competenze per valutarli e intervenire.
Perché rinviare può essere la scelta responsabile
Un ritardo può essere frustrante per chi pianifica aggiornamenti o attende nuove funzionalità. Ma pubblicare una versione importante con problemi ancora da chiarire può comportare rischi maggiori. Nel software infrastrutturale, la stabilità conta quanto l’aggiunta di nuove capacità.
Il progetto ha scelto di prolungare il percorso verso la versione finale e di includere altre correzioni prima del rilascio. La data pianificata per PostgreSQL 19 è il 19 novembre 2026; il secondo release candidate è previsto per il 12 novembre.
Una lezione per i progetti open source
La vicenda va oltre PostgreSQL. Gli strumenti di analisi automatica possono ampliare la quantità di codice controllata e rendere più facile esplorare comportamenti complessi. Ma ogni risultato va interpretato: un’anomalia non è sempre un bug, e un bug segnalato non è necessariamente semplice da correggere.
Per i progetti liberi, questo significa che l’adozione dell’AI non riguarda solo la scelta degli strumenti. Richiede anche processi di triage, priorità chiare e risorse per la revisione. In un progetto mantenuto da una comunità, il tempo delle persone che valutano le modifiche è una risorsa essenziale.
Per chi usa PostgreSQL, la notizia invita soprattutto a non pianificare un aggiornamento sulla base di una data presunta: è meglio seguire gli annunci ufficiali del progetto e provare le nuove versioni in ambienti di test prima di adottarle in produzione.
In breve: l’AI può aiutare a trovare più difetti e più in fretta, ma la qualità finale dipende ancora dalla capacità dei manutentori di capire quali segnalazioni contano e come risolverle in modo sicuro. Il ritardo di PostgreSQL 19 mostra che rendere più veloce l’analisi non elimina il lavoro di manutenzione: può, anzi, renderlo più urgente.