PostgreSQL 19 Gecikti Çünkü Artık Çok Daha Fazla Hata Bulunuyor

Öngörülebilir Takvimden Beklenmedik Gecikmeye#

Son on yılda PostgreSQL ana sürümlerinin yayınlanma zamanlaması oldukça öngörülebilir bir hal almıştı: Eylül ortasından önce değil ve Ekim ortasından sonra da değil. Ancak 2026 yılı bu geleneği bozuyor. PostgreSQL 19 sürümünün Kasım ayından önce yayınlanması pek olası görünmüyor ve projenin sürümü daha da ileri bir tarihe ertelemesi ihtimal dışı değil.

Üstelik bu yıl, oldukça büyük birkaç özellik beta sürecinin çok geç bir aşamasında geri çekildi (revert edildi). Her yıl 8 Nisan'da gerçekleşen özellik dondurma (feature freeze) tarihinden hemen sonra büyük özelliklerin geri çekilmesi alışılmadık olmasa da, 27 Ağustos ile 15 Eylül gibi geç tarihler arasında birden fazla ana özelliğin sürümden çıkarılması oldukça sıra dışıdır:

• UPDATE/DELETE FOR PORTION OF
• SQL Property Graph Queries (SQL/PGQ)
• ALTER TABLE … MERGE PARTITION/SPLIT PARTITION

Neler Oldu? Kısa Cevap: LLM'ler#

Bu gecikmenin ve iptallerin arkasındaki temel neden Büyük Dil Modelleri (LLM'ler) oldu. Her yazılım hata içerir; PostgreSQL'in kod tabanı ise devasa, karmaşık ve eskidir. CVS'ten dönüştürülen git geçmişi 30 yıldan daha eskiye dayanır ve ilk kodlar bundan on yıl önce yazılmıştır. Bu devasa kod yığını her zaman çok sayıda hata barındırıyordu ancak bu durum PostgreSQL'in popüler veya başarılı olmasını engellememişti.

Bugün değişen şey, bu hataları bulmanın çok daha kolay hale gelmesidir. Hataları düzeltmek de kolaylaştı ancak hata bulma hızıyla aynı oranda değil.

Verilerle Hata Bildirimi ve Geriye Dönük Yamalar (Back-Patch)#

8 Nisan ile 25 Eylül tarihleri arasındaki commit istatistikleri, yapay zekanın proje üzerindeki etkisini net bir şekilde ortaya koyuyor:

• 2025 (8 Nisan – 25 Eylül): master dalına 1037 commit, REL_18_STABLE dalına 724 commit ve bir önceki sürüm olan REL_17_STABLE dalına 248 commit yapıldı.
• 2026 (8 Nisan – 25 Eylül): master dalına 1443 commit, REL_19_STABLE dalına 1169 commit ve bir önceki sürüm olan REL_18_STABLE dalına 433 commit yapıldı.

Yalnızca master dalına giden commit sayısına bakıldığında geçen yıla göre hafif bir düşüş görülse de, geliştirilmekte olan sürüme geriye dönük uygulanan (back-patched) commit sayısı %60'tan fazla arttı. Sadece mevcut sürüme değil, en az bir önceki sürüme (REL_18_STABLE) yapılan geriye dönük yamaların sayısı ise tek bir yılda %74'ün üzerinde sıçradı.

Bu artışın nedeni geliştiricilerin (committers) bu yıl daha dikkatsiz olması değil; aksine geçmiş yıllardaki kadar muhafazakar çalışmalarına rağmen yaptıkları hataların LLM'ler tarafından hızla tespit edilmesidir. İnternetteki çok sayıda kullanıcı artık LLM'leri kullanarak buldukları PostgreSQL hatalarını raporluyor ve çekirdek ekip tüm zamanını bunları düzeltmekle geçiriyor.

Yazılım Geliştirme ve Öğrenme Açısından Pratik Çıkarımlar#

Robert Haas'ın belirttiği üzere, yaşanan gecikmede iki temel faktör rol oynuyor ve bunlar modern yazılım mühendisliği ile AI Test Stratejileri açısından kritik dersler barındırıyor:

• Asimetrik Hız ve İnsan İncelemesi Darboğazı: Çok daha fazla hata bulunduğu için bunları düzeltmek daha fazla zaman alıyor. LLM'ler hata tespiti konusunda devasa bir ölçek sağlasa da, kod inceleme (code review) süreçleri hala insan kapasitesine bağlıdır.
• Standartlara Uygunluk Sorunu: LLM'ler hata düzeltme taslakları oluşturabilir ancak bu yamalar her zaman doğru veya PostgreSQL standartlarıyla uyumlu değildir. Bu nedenle her düzeltmenin mutlaka insanlar tarafından incelenmesi ve onaylanması gerekir; yani yapay zeka kod üretse bile mimari standartları ve kod kalitesini doğrulama sorumluluğu geliştiricidedir.