PostgreSQL 19, 19 Kasım'da duyuruluyor — PostgreSQL 14 desteği günler önce sona eriyor

Aynı haftada hem bir sürüm tarihi hem de bir bitiş tarihi

Dev.to'da özetlenen proje duyurusuna göre PostgreSQL 19, 19 Kasım 2026'da genel kullanıma açılıyor. İkinci release candidate olan RC 2 ise bir hafta önce, 12 Kasım'da, desteklenen tüm sürümler için yapılan üç aylık minor sürüm turuyla birlikte geliyor.

Aynı 12 Kasım tarihi, PostgreSQL 14 için yolun sonu anlamına geliyor. Proje her büyük sürümü ilk çıkışından itibaren beş yıl boyunca hata ve güvenlik düzeltmeleriyle destekliyor ve dalı son bir minor sürümle kapatıyor — bu durumda 14.24. Sürüm 14 ilk kez 30 Eylül 2021'de çıktığından, 12 Kasım'dan sonra onu çalıştıran bir cluster artık hiçbir düzeltme almıyor.

PostgreSQL 19'da neler var

Günlük operasyonlar için öne çıkan özellik REPACK: hem VACUUM FULL hem de CLUSTER komutlarının yerine geçen tek bir komut. Eski komutlar uyumluluk için hâlâ mevcut. REPACK (CONCURRENTLY) bir tabloyu access-exclusive lock almadan yeniden kuruyor; brifing, operatörlerin fiilen kullanacağı varyantın bu olduğunu belirtiyor.

Planner davranışı iki uzantı kazanıyor. pg_plan_advice planner kararlarını stabil hale getirip yönlendirirken, pg_stash_advice saklanan advice'ı sorguya özel olarak otomatik uyguluyor. Bakım tarafında ise autovacuum paralel index işleme ve hangi tabloları önce ziyaret edeceğine karar veren bir puanlama sistemi kazanıyor; I/O worker süreçleri io_min_workers ve io_max_workers ile ayarlanabiliyor.

Yoğun cluster'ları en çok etkileyen iki değişiklik replication tarafında: logical replication artık sunucuyu yeniden başlatmadan wal_level'ın replica yapılmasıyla etkinleştirilebiliyor ve sequence değerleri mantıksal olarak replicate ediliyor. Yeni WAIT komutu ise bir standby'ın belirli bir log konumu yazılana, flush edililene veya replay edilene kadar beklemesini sağlıyor.

Yükseltilen bir cluster'da değişen varsayılanlar

Dev.to'da aktarılan sürüm notlarına göre, bir cluster 19'a restore edildiğinde beş varsayılan değişiyor:

• JIT compilation artık devre dışı geliyor; çünkü onu tetikleyen optimizer maliyeti güvenilmez çıktı. Ağır analitik sorgular çalıştıran sitelerin bunu bilerek yeniden etkinleştirmesi gerekiyor.
• max_locks_per_transaction 64'ten 128'e çıkıyor; altta yatan lock boyutu tahsisi değiştiğinden, önceki kapasiteyi korumak için ilgili ayarların iki katına çıkarılması gerekiyor.
• standard_conforming_strings artık sunucuda her zaman açık; ayar kapalıyken 19 öncesi bir pg_dump'ın ürettiği dump, 19'a yüklenemeyecek.
• RADIUS kimlik doğrulaması kaldırıldı; proje, yalnızca UDP kullanan transport'ının güvenli hale getirilemeyeceğini düşünüyor.
• inet ve cidr tiplerindeki index'ler önceki opclass'lar yerine varsayılan olarak GiST kullanıyor.

Sürüm 14'ten çıkış yolu

Sürüm notları üç göç yolunu kabul ediyor: pg_dumpall ile dump ve restore, pg_upgrade veya logical replication. Bunlardan pg_upgrade, belirli cluster'lar üzerinde çalışmayı reddettiği için açık preflight kontrollerini hak ediyor. Reddetme koşullarından ikisi önceden test etmeye değer: inet veya cidr kolonlarındaki btree_gist index'leri ile veritabanı, role veya tablespace adlarına gömülü carriage return ve line feed karakterleri. Ayrıca MULE_INTERNAL encoding kaldırıldığından, onu kullanan veritabanlarının farklı bir encoding'e dump ve restore edilmesi gerekiyor.

Brifingin pratik önerisi, seçilen yolu üretim benzeri bir kopyada prova etmek, kritik sorguları üzerinde çalıştırmak ve gerçek göçe onay vermeden önce yedekleri, geri alma prosedürünü ve bakım penceresi süresini doğrulamak. Belgelenmiş her uyumsuzluk önceden bulunabilecek bir gerçektir ve bunlardan herhangi biri, göç sırasında ortaya çıkarsa süreci sabote edebilir.

Neden önemli

Hâlâ PostgreSQL 14 kullanan ekipler sert bir son tarihle karşı karşıya: 12 Kasım'dan sonra, yani yeni sürüm gelmeden bir hafta önce, hiçbir düzeltme gelmeyecek. Yükseltme, bu zamanlamanın ima ettiğinden daha az riskli; çünkü engelleyici koşullar — standart dışı encoding'ler, btree_gist opclass'ları, string işleme varsayılanları — başarısız bir bakım penceresiyle değil, bir preflight sorgusuyla keşfedilebiliyor. Proje ayrıca destek sonu tarihlerini yıllar öncesinden duyuruyor; destek tablosu sürüm 18'i Kasım 2030'a kadar listeliyor. Herhangi bir kurum için, üretimdeki veritabanı sürümü aslında bilinen bir vadesi olan planlanmış bir yükümlülüktür; sürpriz değil.