PostgreSQL 19 çıkış tarihi artık 19 Kasım 2026 olarak netleşti; bu, projenin eylülde öngördüğünden yaklaşık bir ay sonra. İlk sürüm adayı (RC1) 15 Ekim'de yayınlandı, ikinci aday 12 Kasım'da geliyor ve bu süreçte sekiz ila on civarında önemli özellik sürümden çıkarıldı. Nedenlerden biri yeni olduğu için öne çıkıyor: LLM destekli kod incelemesi, bakımcıların düzeltebileceğinden daha hızlı hata buldu. Production'da Postgres çalıştırıyorsanız, hele hâlâ PostgreSQL 14 kullanıyorsanız, yükseltme takviminiz daraldı.

PostgreSQL 19 çıkış tarihi neden kaydı

24 Eylül'de Beta 4 yayınlandığında proje, sürüm adayını ekim başında bekliyordu ve GA'nın da aynı ay gelebileceğini söylüyordu. Öyle olmadı. RC1 15 Ekim'de çıktı ve PostgreSQL Global Development Group planlanan GA tarihini 19 Kasım olarak duyurdu.

Takvime bir adım da eklendi. RC1 duyurusuna göre, desteklenen sürümler için 12 Kasım'da çıkacak güncelleme sürümü çok sayıda düzeltme içerecek ve sürüm ekibi bu düzeltmelerin GA öncesinde 19'a da girmesini istiyor. Bu yüzden RC2 aynı gün yayınlanacak. Duyurunun dili temkinli: test sırasında yeni bir erteleme ya da ek aday gerektiren bir sorun çıkmazsa tarih 19 Kasım.

Aşama Tarih (2026)
Feature freeze 8 Nisan
Beta 1 4 Haziran
Beta 2 16 Temmuz
Beta 3 13 Ağustos
Beta 4 24 Eylül
RC1 15 Ekim
RC2 12 Kasım
Planlanan GA 19 Kasım

AI destekli inceleme sürümü neden yavaşlattı

Postgres'te bir özelliğin geç aşamada geri alınması tek başına olağan dışı değil. Committer Peter Eisentraut 9 Ekim tarihli blog yazısında, döngü başına bir revert'in beklenebileceğini yazıyor. Bu kez ise, nasıl saydığınıza bağlı olarak sekiz ila on önemli özellik geri alınmış; bazıları beta döneminin epey sonunda.

Asıl dikkat çekici olan açıklaması. Ciddi sorunların yanında, uç durumlarla ilgili, görece zararsız hatalardan oluşan uzun bir kuyruk da varmış. Eskiden bunların çoğu zamanla ortaya çıkar, sonraki beş yıl içinde parça parça düzeltilirdi. LLM destekli incelemeyle hepsi bir anda yüzeye çıktı; Eisentraut önünde kırk kadar hata raporu olan bir listeden söz ediyor. Ortalama düzeltme birkaç satır olsa bile her raporun sabit bir maliyeti var: yeniden üretmek, tartışmak, yamayı gözden geçirmek, commit etmek. Bunu kırkla çarpınca beta penceresi bitiyor.

Eisentraut başka etkenleri de sayıyor: bazı özelliklerde ciddi mimari kusurlar vardı, sistemin karmaşıklığı bazı özellikleri doğru yapmayı çok zorlaştırıyor ve nisan–ağustos arasında birçok kıdemli geliştirici güvenlik açıklarını kapatmakla meşguldü; bu da beta dönemindeki olağan inceleme ve testleri azalttı.

Eisentraut bunun "vibe coding" kaynaklı olmadığını da açıkça belirtiyor. Geri alınan özelliklerin çoğu, LLM incelemesinin bugünkü kadar işe yaramadığı dönemde yazılmış; yani kod commit edildikten sonra fiili kalite çıtası yükselmiş. Projenin Beta 4 notlarındaki ilke net: PostgreSQL her şeyden önce güvenilir olmalı.

Bir yan etki de var: The Register'a göre geri alınan özellikler gelecek yılki PostgreSQL 20'ye kalıyor. Oysa Eisentraut birkaç ay önce 20'nin yeni özellik içermeyip yalnızca hata düzeltmelerinden oluşabileceğini söylemişti.

PostgreSQL 19'da neler var, neler yok

Geri alınanlar, yani 19'da olmayacaklar:

  • SQL/PGQ ile property graph sorguları
  • Data checksum'ların online olarak açılıp kapatılması
  • FOR PORTION OF ile temporal update ve delete
  • ALTER TABLE ... MERGE PARTITIONS ve SPLIT PARTITIONS
  • GROUP BY ALL (temmuzda, Beta 3'ten önce geri alındı)

Eisentraut'un öne çıkardığı ve 19'da kalanlardan bazıları:

  • REPACK CONCURRENTLY
  • Sequence'lerin logical replication ile aktarımı (daha önce bir kez geri alınmış bir özellik)
  • pg_plan_advice ile planner hinting

Yol haritanızda SQL içinde graph sorguları ya da büyük time-series tablolarında partition birleştirme/bölme varsa, bunları 19 planınızdan çıkarın. PostgreSQL 20 muhtemel adres, ama "muhtemel" bir deadline'ı dayandıracağınız bir taahhüt değil.

Test edilmesi gereken uyumluluk değişiklikleri

Resmi release notes, yükseltmeyi ya da geri yüklemeyi bozabilecek birkaç değişiklik içeriyor:

  • MD5 ile başarılı parola doğrulamasından sonra artık uyarı veriliyor. Rolleri SCRAM'e taşımak için iyi bir hatırlatma.
  • 19 öncesi pg_dump veya pg_dumpall ile, standard_conforming_strings = off ayarıyla alınmış dump'lar 19'a düzgün yüklenmiyor.
  • pg_upgrade, veritabanı, rol veya tablespace adında satır başı (CR) ya da satır sonu (LF) karakteri olan cluster'ları yükseltmeyi reddediyor.
  • inet ve cidr için varsayılan index opclass btree_gist yerine GiST oldu; btree_gist inet/cidr index'i olan cluster'ları pg_upgrade reddediyor.

Mevcut cluster'ınızda bugün çalıştırabileceğiniz birkaç hızlı kontrol:

-- Hâlâ MD5 parola hash'i kullanan roller (superuser gerekir)
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';

-- pg_upgrade'i engelleyecek adlar (CR veya LF)
SELECT datname FROM pg_database WHERE datname ~ '[\r\n]';
SELECT rolname FROM pg_roles WHERE rolname ~ '[\r\n]';
SELECT spcname FROM pg_tablespace WHERE spcname ~ '[\r\n]';

-- Dump'larınızın alındığı ortamda çalıştırın
SHOW standard_conforming_strings;

pg_authid tablosunu okuyamadığınız yönetilen servislerde kimlik doğrulama yöntemlerini sağlayıcının kendi araçlarıyla denetleyin.

Aynı haftada üç tarih: PG14 EOL, RC2 ve GA

Haberi acil kılan şey takvim. Resmi siteye göre PostgreSQL 14, 12 Kasım 2026'da düzeltme almayı bırakıyor; bu tarih RC2 ile aynı gün ve planlanan GA'dan bir hafta önce. Projenin sürüm politikasına göre her major sürüm beş yıl destekleniyor, ardından son bir minor sürüm çıkıyor ve sürüm end-of-life oluyor.

Bu durumda PG14 kullananlar için "19'u bekleriz" seçeneği ortadan kalkıyor. GA zamanında çıksa bile, mevcut sürümünüzün desteği bittikten bir hafta sonra yepyeni bir major sürüme production'da geçmek sağlıklı bir plan değil.

Azure Database for PostgreSQL kullanıyorsanız

Microsoft'un desteklenen sürümler sayfası, flexible server'daki en yeni sürüm olarak 18'i, güncel minor olarak da 18.6'yı gösteriyor. Microsoft, PostgreSQL 19'un ne zaman sunulacağını henüz duyurmadı. Dokümantasyona göre desteklenmeyen sürümlerdeki sunucular otomatik olarak extended support'a alınıyor, varsa ek süre bittikten sonra ücretlendirme başlıyor ve Microsoft bunu kalıcı çözüm değil, geçici bir köprü olarak görmenizi öneriyor. Microsoft ayrıca bazı extension'ların PostgreSQL 18'de desteklenmediğini belirtiyor; 18'i hedef seçmeden önce extension listesine bakın. Kendi sunucularınıza ait kesin tarihleri ikinci el kaynaklar yerine Microsoft dokümantasyonundan ve portaldan kontrol edin.

Ekipler şimdi ne yapmalı

Hâlâ PostgreSQL 14'teyseniz

Şimdi yükseltin ve hedef olarak 19 yerine 17 ya da 18'i seçin. Pratik bir sıra:

  1. Kullandığınız extension'ların envanterini çıkarın ve hedef sürümde mevcut olduklarını doğrulayın.
  2. Kesinti bütçenize göre pg_upgrade veya logical replication ile, production boyutunda veriyle staging'de prova yapın.
  3. Yukarıdaki uyumluluk kontrollerini ve uygulamanızın tüm test suite'ini çalıştırın.
  4. Geri dönüş planı olan bir geçiş penceresi belirleyin.

15–18 arasındaysanız ve 19 ilginizi çekiyorsa

REPACK CONCURRENTLY ya da pg_plan_advice sizin için gerçek bir sorunu çözüyorsa, RC1'i şimdiden staging'de ayağa kaldırın. Gerçekçi veri yükleyin, uyumluluk kontrollerini yapın, en ağır sorgularınızı benchmark edin ve çok sayıda düzeltme taşıyacağı için RC2'de testi tekrarlayın. Production'a GA gününde değil, ilk minor sürümlerden sonra geçin.

Yol haritası geri alınan özelliklere dayanıyorsa

Bugün elinizdeki araçlarla yeniden planlayın: graph dolaşımını uygulama katmanında yapmak, partition bakımını elle yönetmek, geçerlilik aralığını açık başlangıç/bitiş kolonlarıyla tutmak gibi. PostgreSQL 20 beta'ya geldiğinde yeniden değerlendirin.

Kendi ekibiniz için ders: bulmaya değil, düzeltmeye bütçe ayırın

Bu hikâye aslında yalnızca Postgres'le ilgili değil. Mevcut bir kod tabanına LLM destekli inceleme ya da fuzzing ekleyen her ekip aynı duvara çarpacak: tespit anında ölçekleniyor, triage ve düzeltme ise ölçeklenmiyor. Eisentraut'un önerisi de bu yönde: elle listelenemeyecek uç durumları hızla bulduğu için LLM destekli fuzzing ileride özellik geliştirmenin parçası olmalı.

Kendi ekibinizde bunu şöyle uygulayabilirsiniz:

  • Erken çalıştırın. AI incelemesini lansmandan iki hafta önce release branch'ine değil, geliştirme sırasında feature branch'lere uygulayın.
  • Triage kapasitesi planlayın. Her bulgunun sabit bir maliyeti var. Code review için nasıl mühendis zamanı ayırıyorsanız, buna da ayırın.
  • Eski kodda bir dalga bekleyin. Legacy modüllerdeki ilk tarama bir backlog üretecek. Bunu bir sürümle çakışmaya bırakmak yerine ayrı bir temizlik sprint'i planlayın.
  • Geri almayı ucuz tutun. Feature flag'ler ve küçük, izole merge'ler, bir özelliği tüm sürümü raydan çıkarmadan geri çekmenizi sağlar; Postgres'in yaptığı tam olarak buydu.

Daha az bilinen hatayla çıkan gecikmeli bir sürüm, sistemin doğru çalıştığını gösterir. Asıl hata, araçları benimseyip etraflarındaki süreci değiştirmemek olur.

Öne çıkanlar

  • PostgreSQL 19 GA'sı 19 Kasım 2026 için planlandı, RC2 12 Kasım'da geliyor; tarih RC testlerine bağlı.
  • SQL/PGQ, partition MERGE/SPLIT ve FOR PORTION OF dahil sekiz ila on önemli özellik geri alındı; büyük olasılıkla PostgreSQL 20'ye kalacaklar.
  • PostgreSQL 14, 12 Kasım'da düzeltme almayı bırakıyor; 19'u beklemeden şimdi 17 veya 18'e geçin.
  • 19'u staging'de test edin, MD5 doğrulamasını, dump ayarlarını ve CR/LF içeren adları kontrol edin, production'a ilk minor sürümlerden sonra geçin.
  • AI destekli inceleme kullanacaksanız bulguları düzeltecek kapasiteyi de planlayın ve aracı geliştirme sürecinin başında çalıştırın.