PostgreSQL 14 Desteği 12 Kasım 2026’da Bitiyor: pg_upgrade ve Logical Replication ile Yükseltme Planı

PostgreSQL 14’ün topluluk desteği 12 Kasım 2026’da sona eriyor. Sunucularınız bu tarihten sonra da çalışır; ancak yeni bulunan güvenlik açıkları ve hatalar artık PostgreSQL 14 için kapatılmaz. Yükseltmeyi şimdi planlamanızı, hedef sürüm olarak da PostgreSQL 18’i seçmenizi öneriyoruz.

Bu rehber iki okuyucu için hazırlandı: kararı verecek BT yöneticileri ve yükseltmeyi uygulayacak teknik ekipler. İlk bölümler destek sonunun işletmeye etkisini, hedef sürüm seçimini ve yöntem karşılaştırmasını özetliyor. Sonraki bölümler ise pg_upgrade, logical replication ve dump/restore için test edilmiş adımları içeriyor. Komutları PostgreSQL 14.24 ve 18.6 üzerinde denedik.

Kısaca: PostgreSQL 14 Destek Sonu

Destek Sonu İşletmeniz İçin Ne Anlama Geliyor?

PostgreSQL topluluğu her ana sürümü (major version), ilk yayın tarihinden itibaren beş yıl boyunca destekler. 30 Eylül 2021’de yayımlanan PostgreSQL 14 için bu süre, 12 Kasım 2026’da çıkacak son ara sürümle (minor release) tamamlanıyor.

Destek sonu bir kapanış tarihi değildir; 13 Kasım sabahı hiçbir sunucu durmayacak. Değişen, sürümün bakım durumudur:

Kısacası, PostgreSQL 14’te geçen her ay, yamayla kapatamayacağınız bir risk biriktirir. Yükseltme ne kadar erken planlanırsa, proje o kadar sakin yürür.

Önce Envanter: Hangi Sürümü Kullanıyorsunuz?

Her sunucuda aşağıdaki iki komutu çalıştırın. Script’lerde karşılaştırma yapacaksanız server_version_num daha kullanışlıdır: örneğin 140024, 14.24 anlamına gelir.

SELECT version();
SHOW server_version_num;

14.24’ten eski bir 14.x sürümü kullanıyorsanız, önce son ara sürüme geçin. Ara sürüm güncellemesi dump veya pg_upgrade gerektirmez; ana sürüm yükseltmesine bilinen hatalardan arınmış bir sistemle başlamanızı sağlar.

Hedef Sürüm: PostgreSQL 17 mi, 18 mi?

Her iki sürüme de 14’ten doğrudan geçebilirsiniz; 15 ve 16 üzerinden ara adım atmanız gerekmez. Karar için öne çıkan farklar şunlar:

Önerimiz PostgreSQL 18. Bir yıl daha uzun destek alır ve istatistikler taşındığı için yükseltme sonrasında sistem daha hızlı normal performansına döner. Kullandığınız bir eklenti, uygulama üreticiniz veya bulut sağlayıcınız 18’i henüz desteklemiyorsa PostgreSQL 17 güvenli bir alternatiftir.

PostgreSQL 19’u beklemek için bir neden görmüyoruz. İlk sürüm adayı (RC1) 15 Ekim 2026’da yayımlandı ve genel kullanıma sunulması 19 Kasım 2026 için planlanıyor. Eklentilerin, sürücülerin ve araçların yeni bir ana sürümü desteklemesi ise genellikle birkaç ay sürer.

Hangi hedefi seçerseniz seçin, atladığınız her sürümün sürüm notlarındaki “Migration to Version” bölümünü okuyun. 14’ten gelen uygulamaları en sık şaşırtan değişiklik PostgreSQL 15’tedir: yeni veritabanlarında PUBLIC rolü, public şemasında artık nesne oluşturamaz. Yükseltilen veritabanları mevcut yetkilerini korur; fark, yükseltmeden sonra oluşturduğunuz veritabanlarında ortaya çıkar.

Hangi Yükseltme Yöntemi Size Uygun?

Doğru yöntemi üç soru belirler: Ne kadar kesinti kabul edilebilir? Ek disk veya yeni sunucu var mı? İşler ters giderse nasıl geri dönülecek?

Pratikte seçim çoğunlukla şöyle sonuçlanır:

• Aynı sunucuda kalacaksanız ve birkaç dakikalık ila bir saatlik bir kesinti kabul edilebiliyorsa: pg_upgrade.
• Kesinti dakikalarla sınırlıysa ya da yükseltmeyi yeni donanıma geçişle birleştiriyorsanız: logical replication.
• Veritabanı küçükse ve bu fırsatı bir temizlik projesine dönüştürmek istiyorsanız: dump/restore.

PostgreSQL 18 ayrıca --swap modunu getiriyor. Bu mod, eski veri dizinlerini yeni kümeye taşır ve çok sayıda tablo ve indeks barındıran kümelerde en hızlı seçenek olabilir. Link modunda olduğu gibi, dosya aktarımı başladıktan sonra eski kümeyi başlatmak güvenli değildir.

Azure ve Amazon RDS Kullanıyorsanız

Yönetilen servislerde yükseltmeyi sağlayıcı yürütür, ancak takvim ve maliyet sizin sorumluluğunuzdadır.

Azure, yükseltmeden önce bir ön kontrol çalıştırır ve başarısızlık durumunda geri dönmek için örtük bir yedek alır. Amazon RDS ise PostgreSQL 14.24 için 17.11 ve 18.6’yı doğrudan hedef olarak listeliyor.

Yükseltme Öncesi Kontrol Listesi

Aşağıdaki sorgular envanterin temelini çıkarır. Eklenti sorgusunu her veritabanında ayrı ayrı çalıştırın.

-- Databases, size and collation
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size, datcollate
FROM pg_database WHERE datallowconn ORDER BY pg_database_size(datname) DESC;
-- Installed extensions (run in every database)
SELECT extname, extversion FROM pg_extension ORDER BY extname;
-- Items pg_upgrade or a cutover cares about
SELECT count(*) AS prepared_xacts FROM pg_prepared_xacts;
SELECT slot_name, slot_type, active FROM pg_replication_slots;
SHOW data_checksums;
-- Roles still using MD5 password hashes
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
-- Tables without a primary key (matter for logical replication)
SELECT c.oid::regclass AS table_without_pk
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind = 'r'
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
  AND NOT EXISTS (SELECT 1 FROM pg_index i WHERE i.indrelid = c.oid AND i.indisprimary);

Yöntem 1: pg_upgrade ile 14’ten 18’e

Örnekler, apt.postgresql.org’un Debian ve Ubuntu paket yapısına göre yazıldı; bu yapıda her sürümün programları /usr/lib/postgresql/<sürüm>/bin altında bulunur. PostgreSQL 18 paketlerini 14’ün yanına kurun ve tüm komutları postgres kullanıcısıyla, bu kullanıcının yazabildiği bir dizinden çalıştırın.

1. Yeni kümeyi oluşturun

Yeni kümenin locale ve encoding ayarları eski kümeyle aynı olmalıdır. Bir ayrıntıya dikkat edin: PostgreSQL 18, data checksum’ı varsayılan olarak açar; pg_upgrade ise iki kümede bu ayarın aynı olmasını şart koşar. Varsayılan ayarlarla kurulmuş bir 14 kümesinde checksum kapalı olduğu için --no-data-checksums parametresini kullanın. Aksi halde kontrol, “old cluster does not use data checksums but the new one does” hatasıyla durur.

OLD=/usr/lib/postgresql/14/bin
NEW=/usr/lib/postgresql/18/bin
cd /var/lib/postgresql/upg
$NEW/initdb -D ../pg18 -U postgres --locale=en_US.UTF-8 -E UTF8 --no-data-checksums

2. Uyumluluk kontrolünü çalıştırın

Kontrol, PostgreSQL 14 çalışırken yapılabilir. Gerçek yükseltmede kullanacağınız modu (--link gibi) burada da belirtin.

$NEW/pg_upgrade -b $OLD -B $NEW -d ../pg14 -D ../pg18 -p 5414 -P 5418 --check --link

Testimizde ilk kontrol, “Checking for reg* data types in user tables” adımında durdu ve sorunlu kolonu pg_upgrade_output.d altındaki tables_using_reg.txt dosyasına yazdı. Bu veri tipleri, pg_upgrade’in koruyamadığı sistem kimliklerini (OID) saklar. Kolonu 14 sunucusunda text tipine çevirdikten sonra kontrol “Clusters are compatible” sonucuyla tamamlandı.

3. PostgreSQL 14’ü durdurun ve yükseltin

$OLD/pg_ctl -D ../pg14 -w stop -m fast
$NEW/pg_upgrade -b $OLD -B $NEW -d ../pg14 -D ../pg18 -p 5414 -P 5418 --link --jobs 2

İşlem “Upgrade Complete” mesajıyla biter. Eklentilerin yeni sürümleri varsa pg_upgrade bir update_extensions.sql dosyası ve eski kümeyi silmek için delete_old_cluster.sh script’i oluşturur. Yeni küme tüm kontrollerden geçmeden ve yeni bir yedek alınmadan bu script’i çalıştırmayın.

4. PostgreSQL 18’i başlatın ve işlemi tamamlayın

pg_upgrade yapılandırma dosyalarını taşımaz. Uygulamaları yeni kümeye yönlendirmeden önce pg_hba.conf dosyasını ve gerekli postgresql.conf ayarlarını aktarın. Ardından sunucuyu başlatın, eklentileri güncelleyin ve eksik istatistikleri oluşturun:

$NEW/pg_ctl -D ../pg18 -o "-p 5432" -l ../pg18.log -w start
psql -U postgres -f update_extensions.sql
$NEW/vacuumdb -U postgres --all --analyze-in-stages --missing-stats-only
$NEW/vacuumdb -U postgres --all --analyze-only --jobs 2

Testimizde PostgreSQL 18, henüz hiç ANALYZE çalıştırılmadan tablonun istatistiklerine sahipti; oluşturulan script de pgcrypto eklentisini 1.3’ten 1.4’e güncelledi. Küme, 14’teki gibi data_checksums = off olarak kaldı.

Streaming replication ile çalışan standby sunucularınız varsa, pg_upgrade dokümantasyonu bunların birincil sunucudan sonra rsync ile nasıl yükseltileceğini adım adım anlatır. Bu bölümü özellikle dikkatli planlayın: buradaki bir hata, standby sunucuları sıfırdan kurmanız anlamına gelir.

Yöntem 2: Logical Replication ile Kesintisiz Geçiş

Logical replication, veriyi yeni bir PostgreSQL 18 sunucusuna kopyalar ve geçiş anına kadar değişiklikleri aktarmaya devam eder. Eski sunucu süreç boyunca çalıştığı için kesinti yalnızca geçiş anıyla sınırlı kalır.

Başlamadan önce 14 sunucusunda wal_level = logical ayarını yapın (yeniden başlatma gerektirir) ve replikasyon kullanıcısına pg_hba.conf üzerinden erişim izni verin.

1. PostgreSQL 14’te publication oluşturun

CREATE ROLE repl_user WITH LOGIN REPLICATION PASSWORD 'change_me';
GRANT SELECT ON orders TO repl_user;
CREATE PUBLICATION upgrade_pub FOR TABLE orders;

Publication’a eklenen her tablonun, UPDATE ve DELETE işlemlerini aktarabilmek için bir replica identity’ye ihtiyacı vardır. Primary key’i olmayan tablolar, kaynak sunucuda “cannot update table … because it does not have a replica identity and publishes updates” hatası verir. Bu tablolara primary key ekleyin; mümkün değilse son çare olarak ALTER TABLE ... REPLICA IDENTITY FULL kullanın.

2. Rolleri ve şemayı PostgreSQL 18’e kopyalayın

Logical replication tablo yapısını ve DDL komutlarını aktarmaz; bunları önceden taşımanız gerekir. PostgreSQL 18’in istemci araçlarını 14 sunucusuna karşı çalıştırın ve pg14-host yerine kendi sunucu adınızı yazın.

pg_dumpall -h pg14-host -U postgres --globals-only -f globals.sql
psql -U postgres -f globals.sql
pg_dump -h pg14-host -U postgres -d shop --schema-only --no-publications -f shop_schema.sql
psql -U postgres -d shop -v ON_ERROR_STOP=1 -f shop_schema.sql

Rolleri yüklerken “role “postgres” already exists” hatası normaldir. Bunun dışındaki her hatayı inceleyin.

3. PostgreSQL 18’de subscription oluşturun

CREATE SUBSCRIPTION upgrade_sub
  CONNECTION 'host=pg14-host port=5432 dbname=shop user=repl_user password=change_me'
  PUBLICATION upgrade_pub;
-- 'r' means the initial copy is done and the table is streaming
SELECT srrelid::regclass AS table_name, srsubstate FROM pg_subscription_rel;

Subscription, kaynak sunucuda bir replication slot açar. Slot var olduğu sürece 14 sunucusu işlem günlüğünü (WAL) silmez, bu slot için saklamaya devam eder. Senkronizasyon süresince eski sunucunun disk alanını izleyin.

4. Geçişi yapın

PostgreSQL 14’te uygulamanın yazma işlemlerini durdurun ve yeni sunucunun tüm değişiklikleri aldığını doğrulayın:

-- On PostgreSQL 14: lag_bytes must be 0
SELECT application_name, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;

Ardından PostgreSQL 18’de üç işlem kalır: senkronizasyon sırasında değişen DDL’leri uygulamak, sequence değerlerini ileri almak ve subscription’ı kaldırmak. DROP SUBSCRIPTION, kaynak sunucudaki slot’u da siler.

ALTER TABLE orders ADD COLUMN note text;   -- DDL that was added on 14 during the sync
SELECT setval('orders_id_seq', (SELECT max(id) FROM orders));
DROP SUBSCRIPTION upgrade_sub;

Son olarak 14 sunucusunda SELECT count(*) FROM pg_replication_slots; sorgusunun 0 döndürdüğünü kontrol edin. Unutulan bir slot, eski sunucunun diski dolana kadar WAL biriktirmeye devam eder.

Yöntem 3: pg_dump ve pg_restore

En basit yöntemdir ve tüm indeksleri yeni sunucuda baştan oluşturur. Veritabanını bakım için ayrılan süre içinde yedekleyip geri yükleyebiliyorsanız iyi bir seçenektir. PostgreSQL dokümantasyonu, yeni sürümün pg_dump ve pg_dumpall araçlarının kullanılmasını önerir.

pg_dumpall -h pg14-host -U postgres --globals-only -f globals.sql
pg_dump -h pg14-host -U postgres -d shop -Fc -f shop.dump
createdb -U postgres shop_restored
pg_restore -U postgres -d shop_restored --jobs 2 --no-publications --no-subscriptions shop.dump

Custom format (-Fc), --jobs ile paralel geri yüklemeye olanak tanır. Logical replication’dan farklı olarak dump, sequence değerlerini de taşır. Geri yüklenen veritabanında optimizer istatistikleri bulunmadığı için işlemden sonra ANALYZE çalıştırın.

Collation, glibc ve REINDEX

Metin kolonlarındaki indeksler, işletim sisteminin sıralama kurallarına (glibc collation) bağlıdır. Yükseltmeyle birlikte daha yeni bir işletim sistemi sürümüne de geçiyorsanız, bu indeksleri canlıya almadan önce yeniden oluşturun. Bu tür değişikliğin en bilinen örneği glibc 2.28’dir.

Her yöntem bu riskten aynı ölçüde etkilenmez:

• pg_upgrade indeksleri olduğu gibi taşıdığı için etkilenir.
• Dump/restore ve logical replication indeksleri yeni sunucuda baştan oluşturduğu için etkilenmez.
• ICU collation kullanan kolonlar glibc değişikliklerinden etkilenmez.

PostgreSQL 15 ve sonrası her veritabanının collation sürümünü kaydeder. Yeni sunucuda kayıtlı sürümle gerçek sürümü karşılaştırabilir, B-tree indekslerini amcheck ile doğrulayabilir ve gerekli indeksleri yeniden oluşturabilirsiniz:

SELECT datname, datcollate, datcollversion,
       pg_database_collation_actual_version(oid) AS actual_version
FROM pg_database WHERE datname = 'satis';
-- Structural check of B-tree indexes
CREATE EXTENSION IF NOT EXISTS amcheck;
SELECT c.relname AS index_name, bt_index_check(c.oid, true) AS ok
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_am a ON a.oid = c.relam AND a.amname = 'btree'
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public';
-- Indexes that depend on a collatable column
SELECT DISTINCT ic.relname AS index_name
FROM pg_index i
JOIN pg_class ic ON ic.oid = i.indexrelid
JOIN pg_attribute a ON a.attrelid = i.indrelid AND a.attnum = ANY (i.indkey)
JOIN pg_namespace n ON n.oid = ic.relnamespace
WHERE a.attcollation <> 0 AND n.nspname NOT IN ('pg_catalog', 'information_schema');
-- Rebuild without blocking writes, then record the current collation version
REINDEX INDEX CONCURRENTLY musteri_sehir_idx;
ALTER DATABASE satis REFRESH COLLATION VERSION;

Türkçe veriyle çalışanlar için bir test sonucu: tr_TR.UTF-8 locale’iyle oluşturduğumuz veritabanında lower('IŞIK') ve upper('istanbul'), yükseltmeden önce ve sonra aynı şekilde ışık ve İSTANBUL döndürdü; şehir kolonundaki indeks de kullanılmaya devam etti.

Geri Dönüş Planı

Geri dönüş kararının ölçütünü ve yöntemini yükseltmeden önce yazılı olarak belirleyin. Çalışma sırasında, baskı altında verilen kararlar genellikle süreci uzatır.

Yükseltme Sonrası Kontroller

1. SHOW server_version_num; 18 ile başlayan bir değer (18.6 için 180006) döndürmeli; kritik tabloların satır sayıları kaynakla tutmalı.
2. pg_available_extensions görünümünde installed_version ile default_version değerlerini karşılaştırın ve geride kalan eklentileri güncelleyin.
3. İstatistiklerin oluştuğundan emin olun: pg_upgrade sonrasında yukarıdaki vacuumdb komutlarını, dump/restore ve bulut servislerinde ise ANALYZE’ı çalıştırın.
4. Varsayılanı değişen ayarları gözden geçirin: password_encryption, io_method ve data_checksums.
5. Uygulama testlerini çalıştırın; ilk iş günü boyunca sunucu loglarını ve yavaş sorguları yakından izleyin.
6. PostgreSQL 18 üzerinde yeni bir tam yedek alın ve geri yüklemeyi test edin. 14’te alınmış fiziksel yedekler ve WAL arşivleri PostgreSQL 18 ile geri yüklenemez.
7. Geçici kaynakları temizleyin: eski küme dosyaları (yeni yedek alındıktan sonra), replication slot’lar ve geçici roller.

Ne Zaman Uzman Desteği Almalısınız?

Eklentisi olmayan, tek ve küçük bir veritabanının yükseltmesi bir hafta sonu çalışmasıdır. Aşağıdaki durumlardan biri sizin için geçerliyse deneyimli bir ekiple çalışmanızı öneririz:

• Veritabanı büyük ve iş birimleri yalnızca birkaç dakikalık kesintiyi kabul ediyor.
• Streaming replica’lar, Patroni gibi bir yüksek erişilebilirlik yöneticisi veya mevcut bir logical replication yapısı kullanıyorsunuz.
• PostGIS, TimescaleDB gibi eklentiler veya bir uygulama üreticisi hedef sürümü kısıtlıyor.
• Yükseltme; yeni bir işletim sistemi, yeni donanım ya da Azure veya AWS’ye taşınma ile aynı döneme denk geliyor.
• Ekipte bu veritabanlarının geri yüklemesini yakın zamanda deneyen kimse yok.

Aryasoft’un yalnızca kıdemli uzmanlardan oluşan PostgreSQL ekibi, yükseltmeleri uçtan uca planlar ve yürütür: envanter, production kopyası üzerinde prova, geçişin kendisi ve sonrasındaki kontroller. Yükseltme daha kapsamlı bir platform değişikliğinin parçasıysa veritabanı taşıma (migration) hizmetlerimizi inceleyebilirsiniz. Sunucularınız 17 veya 18’e geçtikten sonra düzenli bakım istiyorsanız, uzaktan veritabanı yöneticisi (Remote DBA) hizmetini de içeren yönetilen veritabanı hizmetlerimiz SQL Server’ın yanı sıra PostgreSQL’i de kapsıyor.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Ekim ve Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı. Tarihler, sürümler ve bulut politikaları değişebilir; planınızı kesinleştirmeden önce ilgili sayfadan teyit edin.

1. PostgreSQL: Versioning Policy
2. PostgreSQL: Roadmap (ara sürüm takvimi)
3. PostgreSQL 18 dokümantasyonu: Upgrading a PostgreSQL Cluster
4. PostgreSQL 18 dokümantasyonu: pg_upgrade
5. PostgreSQL 18 sürüm notları
6. PostgreSQL 17 sürüm notları
7. PostgreSQL 15 sürüm notları
8. PostgreSQL 18 dokümantasyonu: vacuumdb
9. PostgreSQL 18 dokümantasyonu: pg_dump
10. PostgreSQL 18 dokümantasyonu: Logical replication restrictions
11. PostgreSQL 18 dokümantasyonu: Logical replication configuration settings
12. PostgreSQL 18 dokümantasyonu: CREATE SUBSCRIPTION
13. PostgreSQL 18 dokümantasyonu: Collation Support
14. PostgreSQL Wiki: Locale data changes
15. Microsoft Learn: Azure Database for PostgreSQL ana sürüm yükseltmeleri
16. Microsoft Learn: Azure Database for PostgreSQL extended support
17. Microsoft Learn: Azure Database for PostgreSQL sürüm politikası
18. AWS: Amazon RDS for PostgreSQL sürüm takvimleri
19. AWS: RDS for PostgreSQL yükseltmesi için ana sürüm seçimi
20. AWS: Amazon RDS Extended Support
21. AWS: Amazon RDS Extended Support ücretlendirmesi