PostgreSQL Ortamları İçin AI Destekli Teşhis ve DBA Onaylı Çözüm Döngüsü

Ekim 2026'da kararlı ve güncel sürüm PostgreSQL 18; Eylül 2025'te asenkron I/O, varsayılan EXPLAIN BUFFERS, skip scan, uuidv7() ve OAuth kimlik doğrulamasıyla geldi. PostgreSQL 19, 15 Ekim 2026'da RC 1 olarak yayımlandı; RC 2 12 Kasım'da, genel sürüm 19 Kasım 2026'da planlanıyor.

19'un AI destekli teşhis döngüsüne doğrudan dokunan yenilikleri var. REPACK (CONCURRENTLY), VACUUM FULL ve CLUSTER'ın yerini alarak tabloyu uzun süreli kilit almadan yeniden yazıyor. pg_plan_advice ve pg_stash_advice planlayıcı kararlarını sabitleyip sorgu bazında uygulamaya izin veriyor; bu, AI'ın önerdiği plan değişikliklerini kontrollü denemenin yeni bir yolu. Yeni pg_stat_lock ve pg_stat_autovacuum_scores görünümleri, varsayılan açık log_lock_waits ve paralel autovacuum teşhis verisini zenginleştiriyor. Wraparound uyarıları artık 100 milyon işlem kala başlıyor.

Agent tarafında MCP'nin 2026-07-28 sürümü protokolü stateless yaptı ve yetkilendirmeyi sıkılaştırdı. Postgres MCP sunucularındaki salt okuma ve süre sınırlı kısıtlı mod hâlâ prod için doğru varsayılan. Yükseltme planında iki uyarı var: JIT varsayılan olarak kapalı geliyor ve BUFFERPIN bekleme olayının adı BUFFER oldu.

AI destekli teşhisin kalitesi, ona verdiğiniz verinin kalitesiyle sınırlı. Postgres bu konuda cömert. pg_stat_statements eklentisi, normalize edilmiş her sorgu için çağrı sayısını, toplam ve ortalama süreyi, okunan blok sayısını tutar; 'en çok toplam süre harcayan 10 sorgu' listesi çoğu teşhisin başlangıç noktasıdır. pg_stat_user_tables ve pg_stat_user_indexes, sıralı tarama oranını, kullanılmayan indeksleri ve ölü satır (dead tuple) birikimini gösterir. pg_stat_activity ve pg_locks ise o an kimin kimi beklediğini anlatır.

PostgreSQL 18 ile EXPLAIN ANALYZE çıktısında BUFFERS bilgisi varsayılan hale geldi; bir sorgunun yavaşlığının diskten mi bellekten mi okumaktan kaynaklandığı artık ek parametre olmadan görünüyor. PostgreSQL 19 bunu genişletiyor: EXPLAIN (ANALYZE, IO) asenkron I/O etkinliğini gösteriyor, yeni pg_stat_lock görünümü kilit türü bazında istatistik tutuyor ve log_lock_waits varsayılan olarak açık geliyor.

Pratik kural: AI'a 'veritabanım yavaş' demek yerine, pg_stat_statements'tan ilk 10 sorguyu, ilgili tablo istatistiklerini ve EXPLAIN (ANALYZE, BUFFERS) çıktısını verin. Bağlamsız teşhis tahmindir.

LLM'lerin bu alanda en güçlü olduğu yer, uzun ve teknik çıktıları okuyup önceliklendirmek. Yüzlerce satırlık bir EXPLAIN planında, tahmin edilen satır sayısı ile gerçek satır sayısı arasında 1000 katlık bir fark olduğunu ve bunun eski istatistiklere işaret ettiğini hızla yakalayabilir. Nested loop'un milyonlarca kez döndüğü düğümü işaretleyebilir.

İkinci güçlü alan örüntü tanıma: WHERE koşulundaki bir kolonun fonksiyon içine alınması yüzünden indeksin kullanılmaması, OFFSET ile yapılan derin sayfalama, N+1 sorgu desenleri, ORM'in ürettiği gereksiz SELECT * çağrıları. Bunlar deneyimli bir DBA'nın gözünün hemen yakaladığı ama genç bir geliştiricinin saatler harcadığı kalıplar.

Üçüncüsü açıklama: AI, bulguyu uygulama geliştiricisinin anlayacağı dille anlatıp hangi kod satırının değişmesi gerektiğini gösterebilir. Bu, DBA ile geliştirici arasındaki çeviri yükünü ciddi ölçüde azaltır. Zayıf olduğu yer ise iş yükünün tamamını, donanımı ve geçmiş olayları bilmemesi.

Doğru bir teşhis, yanlış bir uygulamayla felakete dönüşebilir. Basit bir örnek: büyük bir tabloda CREATE INDEX komutu, CONCURRENTLY seçeneği olmadan çalıştırılırsa tabloya yazma işlemlerini indeks bitene kadar kilitler. 200 milyon satırlık bir tabloda bu dakikalar sürebilir ve tüm yazma trafiği bekler.

Benzer riskler: tablo şişmesini gidermek için VACUUM FULL ya da CLUSTER çalıştırmak (tablo boyunca ACCESS EXCLUSIVE kilit tutar; PostgreSQL 19'daki REPACK (CONCURRENTLY) bu kilidi yalnızca son dosya değişimine indiriyor, ama MVCC açısından güvenli değil ve kendi kısıtları var), NOT NULL kısıtı eklemek için tam tablo taraması, kolon tipi değiştirmenin tabloyu yeniden yazması, uzun süren bir transaction'ın VACUUM'u engelleyip tablo şişmesine (bloat) yol açması, shared_buffers ya da work_mem gibi parametrelerin bellek tükenmesine neden olacak şekilde artırılması. Kullanılmıyor görünen bir indeksi silmek de risklidir; ayda bir çalışan bir raporun tek dayanağı olabilir.

DBA onayı burada bir bürokrasi değil, bağlam katmanıdır. DBA, bakım penceresini, replikasyon topolojisini, iş takvimini ve geçmiş olayları bilir. AI'ın önerisi doğru olsa bile 'şimdi mi, nasıl, geri dönüş planı ne' sorularını o cevaplar.

AI'ın veritabanına nasıl bağlandığı, onayın kendisi kadar önemli. Güvenli bir kurulumda teşhis ajanı yalnızca salt okuma yetkisi olan, pg_read_all_stats gibi izleme rolleriyle sınırlanmış ayrı bir veritabanı kullanıcısıyla bağlanır. statement_timeout ile her sorgu birkaç saniyeyle sınırlanır, böylece ajanın ürettiği ağır bir sorgu prod'u yormaz.

Açık kaynak Postgres MCP Pro sunucusu bu ayrımı somut olarak uygular: geliştirme için sınırsız, prod için salt okuma transaction'ları ve süre sınırı olan kısıtlı bir mod sunar. Aynı sunucu sağlık kontrollerini ve hipotetik indeks analizini de araç olarak açar.

Uygulama yolu ise ajandan tamamen ayrı olmalı. Ajan bir öneri üretir: SQL, gerekçe, beklenen etki ve geri alma komutu. Bu öneri bir PR veya değişiklik talebi olarak migration aracına girer, DBA inceler ve onaylanan değişiklik normal dağıtım hattından geçer. Ajanın prod'a yazma yetkisi hiç olmaz.

İyi bir AI önerisi 'şu indeksi ekle' demekle yetinmez, neden işe yarayacağını gösterir. HypoPG eklentisi bunu mümkün kılar: indeksi gerçekten oluşturmadan planlayıcıya varmış gibi gösterir ve EXPLAIN ile sorgunun yeni maliyetini hesaplatır. Disk alanı harcanmaz, kilit alınmaz.

Postgres MCP Pro'nun indeks önerici yaklaşımı bu fikre dayanıyor: filtre, join ve sıralamada kullanılan kolonlardan aday indeksler üretir, bunları HypoPG ile dener ve her turda en iyi kazancı sağlayanı seçer. Kazanç yüzde 10'un altına düştüğünde durur ve performans kazancını depolama maliyetiyle tartar.

DBA'ya giden öneri paketi şunları içermeli: hedef sorgu ve mevcut süre, önerilen değişiklik, hipotetik plan maliyeti öncesi ve sonrası, tahmini indeks boyutu, yazma yüküne etkisi ve geri alma komutu. Bu paket, onayı bir güven meselesinden bir kanıt incelemesine çevirir.

Onaylanan bir değişiklik uygulandığında iş bitmiş sayılmaz. Doğrulama adımı, önerinin vaat ettiği etkinin gerçekten oluşup oluşmadığını ölçer. Yeni indeks eklendiyse, hedef sorgunun pg_stat_statements'taki ortalama süresi ve okunan blok sayısı önceki değerle karşılaştırılır. pg_stat_user_indexes'ta indeksin gerçekten kullanıldığı görülür. Yazma gecikmesinde bir artış olup olmadığı izlenir.

Bu döngü, AI sistemini zamanla daha güvenilir kılar. Her önerinin beklenen ve gerçekleşen etkisi kaydedilirse, hangi tür önerilerin tutarlı biçimde işe yaradığı, hangilerinin DBA tarafından sıkça reddedildiği görünür hale gelir. Red gerekçeleri de değerli bir bilgi tabanıdır: 'bu tabloda bakım penceresi dışında değişiklik yapılmaz' gibi kurallar sonraki önerilerde bağlam olarak kullanılabilir.

PostgreSQL 18'in major sürüm yükseltmelerinde planlayıcı istatistiklerini koruması da bu açıdan önemli: yükseltme sonrası plan bozulmaları azalır ve öncesi-sonrası karşılaştırmalar daha anlamlı olur. PostgreSQL 19'a geçerken iki ayrıntıya dikkat: JIT artık varsayılan kapalı, yani JIT'e dayanan analitik sorguların baz çizgisi yeniden ölçülmeli; pg_stat_statements ise generic ve custom plan sayılarını ayrı göstermeye başlıyor.

AI destekli teşhis yalnızca 'site yavaşladı' anında değil, düzenli sağlık kontrollerinde de değerli. Kontrol listesi bilinen başlıklardan oluşur: kullanılmayan, tekrar eden ve geçersiz indeksler; tablo ve indeks şişmesi; buffer cache isabet oranı (OLTP iş yükünde genelde yüzde 99'un üzerinde beklenir); bağlantı kullanımı ve boşta bekleyen transaction'lar; replikasyon gecikmesi; tükenmeye yaklaşan sequence'ler.

Özellikle iki kontrol sessiz felaketleri önler. Birincisi transaction ID wraparound: VACUUM düzgün çalışmazsa Postgres veri bütünlüğünü korumak için yazmayı durdurabilir. PostgreSQL 19 bu uyarıları daha erken veriyor: uyarı eşiği kalan 40 milyondan 100 milyon işleme çıkarıldı. İkincisi integer sequence taşması: 32 bit bir kimlik kolonu yaklaşık 2,1 milyar değerde tükenir ve ekleme işlemleri hata vermeye başlar.

AI'ın katkısı, bu kontrollerin çıktısını haftalık bir özete çevirip önceliklendirmek ve trendi göstermek. Örneğin 'bu sequence mevcut hızla 4 ay içinde tükenecek' bilgisi, panik migration'ı planlı bir işe dönüştürür.