PostgreSQL 14, 12 Kasım 2026'da ömrünün sonuna ulaşıyor ve tüm güvenlik düzeltmeleri sona eriyor

PostgreSQL 14, 12 Kasım 2026'da son minor sürümünü alıyor. Bu tarihten itibaren topluluk, güvenlik yamaları dahil olmak üzere bu sürüm için düzeltme yayınlamayı bırakıyor ve halâ onu çalıştıran tüm kurulumların, önerilen hedef olan PostgreSQL 18'e yükseltme yapması gerekiyor. Bu, dev.to'da yayımlanan ayrıntılı bir yükseltme rehberinin özündeki uyarı.

Beş yıllık destek penceresi kapanıyor

PostgreSQL projesi her major sürümü ilk çıkışından sonra beş yıl boyunca destekliyor, ardından son bir minor sürüm yayınlıyor ve duruyor. Sürüm 14, 30 Eylül 2021'de geldiği için son sürümü, projenin bir sonraki planlı minor sürüm turuyla birlikte 12 Kasım 2026'da geliyor. Minor sürümler hata düzeltmeleri, güvenlik düzeltmeleri ve veri bozulması düzeltmelerinin iletildiği kanal; bunlar durduktan sonra sürüm 14'te sonradan bulunan her şey, mevcut veritabanları çalışmaya devam etse bile düzeltilmeden kalıyor.

dev.to'da alıntılanan sürümleme takvimine göre kalan desteklenen major sürümlerin sonu şöyle: PostgreSQL 15, 11 Kasım 2027; 16, 9 Kasım 2028; 17, 8 Kasım 2029; 18 ise 14 Kasım 2030. PostgreSQL 19, 15 Ekim 2026'da ilk release candidate aşamasına ulaştı ama henüz desteklenenler listesinde değil; rehber de onu beklememek gerektiğini söylüyor — sürüm 18, desteklenen en yeni major sürüm ve önünde en çok yıllık düzeltme var.

Sürüm 14 beklenenden daha fazla yerde saklı

dev.to'ya göre GitHub'da yaklaşık 72.000 herkese açık dosya image: postgres:14 dizgisini içeriyor; bu, 2 Kasım 2026 tarihli yaklaşık bir kod arama sayısı. Rehber alışılmış saklanma noktalarına dikkat çekiyor: postgres:14'e sabitlenmiş compose dosyaları ve Dockerfile'lar, onu service container olarak kullanan CI workflow'ları, image.tag veya appVersion altındaki Helm değerleri ve engine_version (RDS, Aurora), version (Azure) ile POSTGRES_14 (Cloud SQL) gibi Terraform alanları. Etiketlenmemiş bir image: postgres satırı ise başlı başına bir risk; çünkü container oluşturulduğu gün en yeni hangi major sürüm varsa onu çekiyor.

Yönetilen servisler kendi takvimleriyle çalışır

Veritabanını bir bulut sağlayıcısı çalıştırdığında, geçerli olan takvim onunkidir. Amazon RDS for PostgreSQL, sürüm 14'ü 28 Şubat 2027'ye kadar standart destekta tutuyor, ardından 28 Şubat 2030'a kadar Extended Support için ücret alıyor; Google Cloud SQL, Azure ve Heroku ise kendi tarihlerini belirliyor. Yönetilen platformlarda dev.to, manuel araçlar yerine sağlayıcının major sürüm yükseltmesini kullanmayı öneriyor; ancak aynı test adımları yine de geçerli.

Sürüm 18'e üç yükseltme yolu

Ara sürümlerin her biri için release notes okunduğu takdirde 14'ten doğrudan 18'e geçişe izin var. dev.to'da özetlendiği şekliyle PostgreSQL yükseltme dokümantasyonu üç yöntem tanımlıyor.

pg_upgrade, kendinizin işlettiği sunuculara uygun; özellikle link modunda kesinti süresi dakikalarla ölçülüyor. Önce kontrol geçişini çalıştırın, gerçek çalıştırmadan önce her extension'ın paylaşımlı kütüphanesinin sürüm 18 build'ini kurun ve sonrasında vacuumdb -a -Z çalıştırın; çünkü CREATE STATISTICS ile oluşturulan istatistikler taşınmıyor. Bir pürüz: sürüm 18 varsayılan olarak data checksum'ları etkinleştiriyor ve pg_upgrade iki kümenin de eşleşmesini istiyor; bu yüzden checksum'sız bir 14 kümesi, yeni kümenin checksum'lar kapalıyken oluşturulmasını gerektiriyor.

Dump ve restore en basit ama en yavaş yol; küçük veritabanları, yerel geliştirme ve CI için en iyisi. İki tuzak öne çıkıyor: mevcut bir data volume doğrudan postgres:18'e işaret edilemez, çünkü major sürümler data-directory formatını değiştiriyor; ayrıca sürüm 18'den itibaren Docker imajı volume'unun /var/lib/postgresql konumunda değil /var/lib/postgresql/data konumunda olmasını bekliyor.

Logical replication, kesintiye giremeyecek büyük veritabanlarına uygun; switchover süresi saniyelerle ölçülüyor. 14 sunucusunda, yeniden başlatma gerektiren wal_level = logical ayarını istiyor ve katı sınırları var: şemalar, sequence'lar ve large object'ler çoğaltılmıyor; UPDATE ve DELETE ifadelerinin yayılması için tabloların replica identity'si olması gerekiyor.

Geçişten önce neler test edilmeli

dev.to'nun önerisiyle önce CI'yi sürüm 18'e yönlendirin; sonra extension kullanılabilirliğini doğrulayın, her iki sürümde sorgu planlarını EXPLAIN (ANALYZE, BUFFERS) ve pg_stat_statements ile karşılaştırın ve bağlantı driver'larını güncelleyin; çünkü sürüm 18, MD5 parolalarını SCRAM lehine kullanımdan kaldırıyor. Sürüm 15'in davranış değişikliklerine dayanan script'ler de gözden geçirmeyi gerektiriyor: yeni veritabanlarında artık her kullanıcı public şemasında nesne oluşturamıyor ve pg_start_backup ile pg_stop_backup, pg_backup_start ve pg_backup_stop olarak yeniden adlandırıldı.

Neden önemli

12 Kasım'dan sonra çalışmaya devam eden bir sürüm 14 veritabanı güvenli değil: o günden itibaren içinde bulunan her açık asla yamalanmayacak ve GitHub dosya sayısı, maruziyetin yaygın olduğunu gösteriyor. Son tarih kesin, 14'ten 18'e doğrudan yükseltme yolu mevcut ve eforun büyük kısmı migrasyonun kendisinde değil; extension'ları, driver'ları, izinleri ve sorgu planlarını test etmekte.