PostgreSQL 19 Beta 2: Şimdi Test Etmeye Değer mi?

Kısa özet: PostgreSQL 19 Beta 2, 16 Temmuz 2026 tarihinde yayımlandı. Sürüm; temporal veri işlemleri, SQL/PGQ property graph desteği, WAIT FOR komutu, REPACK, logical replication geliştirmeleri, çevrim içi data checksum yönetimi ve yeni gözlemlenebilirlik özellikleri getiriyor. Ancak PostgreSQL 19 hâlâ beta aşamasında ve üretim ortamlarında kullanılmamalı.

Kısa doğrudan cevap

PostgreSQL 19 Beta 2, 2026 sonu veya 2027 içinde PostgreSQL 19’a geçmeyi planlayan ekipler için şimdi test edilmeye değer. Özellikle logical replication, büyük tabloların bakımı, temporal veri, property graph sorguları, replica tutarlılığı veya çevrim içi checksum yönetimi kullanan ekipler erken testten fayda sağlayabilir. Ancak PostgreSQL 19 Beta 2 üretime hazır değildir. PostgreSQL projesi beta sürümlerin production sistemlerinde ve aktif geliştirme projelerinde kullanılmamasını açıkça öneriyor. Özellik ayrıntıları, davranışlar ve API’ler kararlı sürümden önce değişebilir.

PostgreSQL 19 Beta 2 ne zaman yayımlandı?

PostgreSQL Global Development Group, PostgreSQL 19 Beta 2’yi 16 Temmuz 2026 tarihinde yayımladı. Bu, PostgreSQL 19’un ikinci beta sürümüdür. Projenin resmî yol haritası kararlı PostgreSQL 19 sürümünü Eylül 2026 için planlarken Beta 2 duyurusu nihai yayın aralığını Eylül/Ekim 2026 olarak ifade ediyor.

Beta aşamasında yeni ana özelliklerin eklenmesi beklenmez; geliştirme dönemi özellik açısından dondurulmuştur. Bununla birlikte hatalar, uyumsuzluklar ve davranış ayrıntıları nedeniyle mevcut özelliklerde değişiklik yapılabilir veya bazı özellikler kaldırılabilir.

Beta 2, Beta 1’den ne kadar farklı?

PostgreSQL 19 Beta 2 esas olarak yeni özellik eklemekten çok Beta 1’de bulunan özellikleri düzeltmeye ve kararlı hale getirmeye odaklanıyor. Beta 2’de yapılan düzeltmeler arasında şunlar bulunuyor:

• Partitioned tablolar için vacuumdb --analyze-in-stages regresyonunun düzeltilmesi
• Virtual generated column optimizasyonundaki hatanın giderilmesi
• pg_createsubscriber aracının yinelenen publication isimlerini kabul etmesi
• REPACK worker sürecinin FATAL çıkışta temizlenmesi
• FOR PORTION OF temporal tablo sözdiziminde çeşitli düzeltmeler
• SQL/PGQ property graph özelliğinde çeşitli düzeltmeler
• Logical decoding etkinleştirilirken oluşabilen yarış durumunun giderilmesi
• Autovacuum multixact-age puanlama hesabının düzeltilmesi
• postgres_fdw foreign table istatistiklerinin işlenmesinde düzeltmeler

Bu düzeltme listesi, Beta 2’nin Beta 1’e göre daha olgun olduğunu gösterir. Aynı zamanda yeni özelliklerin hâlâ aktif biçimde düzeltildiğini ve production için kararlı kabul edilmemesi gerektiğini de gösterir.

PostgreSQL 19’un öne çıkan yenilikleri

1. REPACK ile tabloları yeniden düzenleme

PostgreSQL 19, tabloları yeniden yazarak ölü tuple’ların kapladığı alanı geri kazanmak için yeni REPACK komutunu getiriyor. VACUUM, çoğu durumda boş alanı PostgreSQL içinde yeniden kullanılabilir hale getirir; fakat dosya boyutunu işletim sistemine geri vermeyebilir. REPACK, tablonun içeriğini yeni bir dosyada yeniden oluşturarak kullanılmayan alanı işletim sistemine geri kazandırabilir.

Temel kullanım

REPACK orders;

Belirli bir index sıralamasına göre tabloyu yeniden düzenlemek için:

REPACK orders USING INDEX orders_created_at_idx;

Daha az engelleyici concurrent çalışma için:

REPACK (CONCURRENTLY) orders USING INDEX;

CONCURRENTLY seçeneği operasyonel kesintiyi azaltmayı hedefler; ancak işlem yine CPU, disk I/O, WAL ve ek geçici alan tüketebilir. Büyük bir production tablo üzerinde kullanılmadan önce gerçek veri büyüklüğüne yakın bir staging ortamında ölçülmelidir.

Kimler test etmeli?

• Sık güncellenen büyük tablolara sahip sistemler
• Bloat problemi yaşayan SaaS uygulamaları
• Kesinti süresi sınırlı olan operasyon sistemleri
• Düzenli VACUUM FULL veya harici repack araçları kullanan ekipler
• Fiziksel tablo sıralamasını yeniden düzenlemek isteyen veri tabanı yöneticileri

REPACK ilerlemesi pg_stat_progress_repack üzerinden izlenebilir. PostgreSQL 19 ayrıca CLUSTER komutunu REPACK ... USING INDEX davranışıyla eşdeğer hale getiriyor.

2. Temporal tablolarda FOR PORTION OF desteği

PostgreSQL 19, uygulama zamanını izleyen temporal tablolarda belirli bir tarih aralığına yönelik UPDATE ve DELETE işlemlerini destekliyor. Örneğin bir fiyat kaydı 2026 yılının tamamı için geçerliyken yalnızca belirli bir dönem değiştirilmek istenebilir:

UPDATE product_prices

FOR PORTION OF valid_at

FROM DATE '2026-06-01'

TO DATE '2026-09-01'

SET price = 1250
WHERE product_id = 42;

PostgreSQL yalnızca belirtilen zaman aralığını günceller. Mevcut kayıt hedeflenen aralığın dışına taşıyorsa satır, geçerlilik dönemlerini koruyacak şekilde bölünebilir. Aynı yaklaşım DELETE ... FOR PORTION OF işlemlerinde de kullanılabilir.

Kullanım alanları

• Fiyat ve tarife geçmişi
• Sözleşme geçerlilik dönemleri
• Çalışan görev ve pozisyon geçmişi
• Sigorta kapsam dönemleri
• Abonelik ve paket değişiklikleri
• Rezervasyon kapasite dönemleri
• Lojistik ve liman tarifeleri
• Kampanya koşullarının tarihsel yönetimi

Neden şimdi test edilmeli?

Beta 2 duyurusunda FOR PORTION OF özelliği için çeşitli düzeltmeler bulunduğu özellikle belirtiliyor. Temporal veri kullanmayı planlayan ekipler kendi constraint, trigger ve eşzamanlı işlem senaryolarını beta döneminde test ederek olası sorunları kararlı sürümden önce tespit edebilir.

3. SQL/PGQ ile property graph sorguları

PostgreSQL 19, SQL standardının bir parçası olan SQL/PGQ yaklaşımını kullanarak property graph tanımlamayı ve sorgulamayı destekliyor. Property graph yapısında:

• Satırlar vertex, yani düğüm olabilir.
• İlişki tabloları edge olabilir.
• Kolonlar graph property olarak kullanılabilir.
• Veri ayrı bir graph veri tabanına taşınmadan ilişkisel tablolarda tutulabilir.

CREATE PROPERTY GRAPH, veriyi fiziksel olarak çoğaltmaz. Mevcut tablo ve view’ları bir graph yapısı altında tanımlayan, view benzeri metadata oluşturur.

Basit örnek

CREATE TABLE people (

person_id bigint PRIMARY KEY, name text NOT NULL );

CREATE TABLE follows (

follower_id bigint REFERENCES people, followed_id bigint REFERENCES people );

CREATE PROPERTY GRAPH social_graph
VERTEX TABLES (

people KEY (person_id) )

EDGE TABLES (

follows SOURCE KEY (follower_id) REFERENCES people (person_id) DESTINATION KEY (followed_id) REFERENCES people (person_id) ); Bu yapı daha sonra GRAPH_TABLE ve path matching sözdizimiyle sorgulanabilir.

Kullanım alanları

• Kullanıcı ve organizasyon ilişkileri
• Yetki bağlantıları
• Ürün öneri ağları
• Tedarik zinciri
• Dolandırıcılık ilişkileri
• Sosyal ağlar
• Varlık ve bağımlılık haritaları
• Yazılım servisleri arasındaki bağlantılar

Sınırlama

PostgreSQL 19 Beta 2 duyurusu property graph özelliğinde birden fazla düzeltme yapıldığını belirtiyor. Bu nedenle property graph desteği araştırma ve prototip için değerlidir; production graph altyapısı için kararlı sürüm ve gerçek ölçek testleri beklenmelidir.

4. Replica okumalarda WAIT FOR

Asenkron replication kullanan uygulamalarda sık görülen problemlerden biri şudur:

• Kullanıcı primary veri tabanına kayıt gönderir.
• Uygulama hemen replica üzerinden okuma yapar.
• Replica henüz ilgili WAL kaydını uygulamamıştır.
• Kullanıcı yeni oluşturduğu veriyi göremez.

PostgreSQL 19’un WAIT FOR komutu, belirli bir WAL Log Sequence Number değerinin standby üzerinde yazılmasını, diske alınmasını veya replay edilmesini beklemeyi mümkün hale getiriyor.

Örnek

WAIT FOR LSN '0/306EE20'
WITH (

MODE 'standby_replay', TIMEOUT '500ms', NO_THROW ); Desteklenen temel modlar:

• standby_replay
• standby_write
• standby_flush
• primary_flush

Ne sağlar?

• Read-your-writes tutarlılığı
• Replica üzerinden okuma yaparken kontrollü bekleme
• Uygulama seviyesindeki manuel polling ihtiyacının azalması
• Belirli işlem sonrası replica tutarlılığının doğrulanması

Dikkat edilmesi gerekenler

• Timeout belirlenmezse işlem süresiz bekleyebilir.
• Replica gecikmesi yüksekse kullanıcı deneyimi kötüleşebilir.
• Her okuma öncesinde kullanılması, replica kullanımının performans avantajını azaltabilir.
• Failover ve standby promotion senaryoları ayrıca test edilmelidir.

WAIT FOR, bütün replikasyonu senkron hale getirmez. Belirli bir işlem veya kullanıcı akışı için gereken tutarlılık noktasını bekleme imkânı sağlar.

5. Logical replication artık sequence değerlerini taşıyabiliyor

PostgreSQL 19, logical replication kapsamında sequence değerlerinin de publisher’dan subscriber’a aktarılmasını destekliyor. Sequence değerlerini yayımlamak için:

CREATE PUBLICATION app_publication

FOR ALL TABLES, ALL SEQUENCES; Subscriber tarafında sequence senkronizasyonu:

• CREATE SUBSCRIPTION sırasında
• ALTER SUBSCRIPTION ... REFRESH PUBLICATION
• ALTER SUBSCRIPTION ... REFRESH SEQUENCES

işlemleriyle yapılabilir. PostgreSQL bu işlemler için geçici bir sequence synchronization worker başlatır.

Neden önemli?

Logical replication ile major version migration yapan ekipler daha önce sequence değerlerini ayrıca yönetmek zorunda kalabiliyordu. Eksik sequence senkronizasyonu şu tür sorunlara neden olabilir:

• Primary key çakışması
• Eski sequence değerinden devam edilmesi
• Cutover sonrasında insert hataları
• Manuel sequence düzeltme ihtiyacı

Sequence replication, özellikle logical replication tabanlı online major upgrade ve minimum kesintili migration senaryolarını kolaylaştırabilir.

Test edilmesi gerekenler

• Sequence ownership ilişkileri
• Cache edilmiş sequence değerleri
• Failover sonrası değerler
• Publication yenilemesi
• Çok sayıda sequence bulunan veritabanları
• Migration cutover anı

6. Logical replication sunucu yeniden başlatılmadan etkinleştirilebiliyor

PostgreSQL 19, wal_level değeri replica iken logical replication ihtiyaca göre etkinleştirilebilen yeni bir yapı getiriyor. Yeni read-only effective_wal_level parametresi, o anda etkin olan WAL seviyesini gösteriyor. Böylece logical replication’ı sürekli açık tutmayan fakat zaman zaman migration veya veri aktarımı için kullanan sistemlerde önceden restart planlama ihtiyacı azalabilir. Bu özellik şu senaryolarda değerlidir:

• Online major version migration
• Geçici veri aktarımı
• Kısa süreli logical decoding
• Analitik sisteme veri gönderme
• Migration araçlarının geçici kullanımı

Ancak WAL üretimi, replication slot’ları, disk kullanımı ve failover davranışı gerçek workload altında ölçülmelidir.

7. Data checksum artık çalışan cluster’da etkinleştirilebiliyor

PostgreSQL 19’dan önce data checksum durumunu değiştirmek genellikle cluster kapalıyken pg_checksums aracıyla gerçekleştiriliyordu. PostgreSQL 19, checksum’ların çalışan cluster üzerinde etkinleştirilmesini ve devre dışı bırakılmasını destekliyor.

Etkinleştirme örneği

SELECT pg_enable_data_checksums();

I/O etkisini sınırlamak için:

SELECT pg_enable_data_checksums(
cost_delay => 10,
cost_limit => 1000

); Durumu kontrol etmek için: SHOW data_checksums; Çevrim içi etkinleştirme sırasında bütün veri sayfaları okunur, checksum hesaplanır ve yeniden yazılır. Bu işlem ciddi disk I/O’su ve WAL üretimi oluşturabilir. Standby üzerinde restartpoint ve replication lag etkisi de yaratabilir.

Kimler test etmeli?

• Checksum kapalı eski cluster’lar
• Kesinti penceresi sınırlı sistemler
• Büyük veri tabanları
• Fiziksel replication kullanan yapılar
• Veri bütünlüğü kontrollerini güçlendirmek isteyen ekipler

Bu özellik çevrim içi çalışsa da “etkisiz” değildir. Production planından önce disk, WAL, replica lag ve backup davranışı test edilmelidir.

8. Autovacuum ve bakım geliştirmeleri

PostgreSQL 19, bakım operasyonlarında birkaç önemli geliştirme getiriyor:

• Autovacuum için paralel worker desteği
• Yeni autovacuum table scoring sistemi
• Sorgu sırasında sayfaları all-visible işaretleyerek gelecekteki vacuum işini azaltabilen yaklaşım
• REPACK
• Partitioned tablolar için geliştirilmiş analiz davranışı
• Vacuum ve analyze loglarında WAL full-page write byte değerleri

Yeni autovacuum_max_parallel_workers ayarı, autovacuum işlemlerinin paralel worker kullanmasını kontrol ediyor. Yeni scoring sistemi ise tabloların vacuum sırasını farklı risk ve bakım sinyallerine göre önceliklendirebiliyor.

Test senaryoları

• Yüksek update/delete hacimli tablolar
• Çok sayıda partition
• Transaction ID wraparound baskısı
• Autovacuum’un sürekli geride kaldığı sistemler
• WAL üretimi yüksek bakım operasyonları
• Yoğun OLTP workload

Varsayılan ayarlar doğrudan production’a taşınmamalıdır. PostgreSQL 19’un scoring davranışı mevcut autovacuum izleme ve alarm eşikleriyle birlikte değerlendirilmelidir.

9. Query planner kontrolü için pg_plan_advice

PostgreSQL 19 ile gelen pg_plan_advice, query planner’ın belirli kararlarını tanımlamak, yeniden üretmek ve kontrollü biçimde değiştirmek için sunulan bir extension’dır. Amaçlar şunları içerebilir:

• İyi olduğu bilinen bir query plan’ını stabilize etmek
• Planner’ın seçmediği alternatifleri test etmek
• Plan değişikliklerini yeniden üretmek
• PostgreSQL sürüm yükseltmelerinde plan regresyonlarını analiz etmek

pg_stash_advice ise query identifier üzerinden tavsiyelerin otomatik uygulanmasını sağlayabilir.

Neden dikkatli kullanılmalı?

Planner tavsiyesi, kötü istatistikleri veya yanlış veri modelini gizlemek için kullanılmamalıdır. Önce şu alanlar kontrol edilmelidir:

• Table statistics
• Extended statistics
• Index yapısı
• Query tasarımı
• Parametre dağılımı
• ANALYZE güncelliği
• Veri büyüklüğü değişimleri

pg_plan_advice, query plan kontrolü için güçlü bir araç olabilir; fakat kalıcı plan sabitleme yaklaşımı veri dağılımı değiştiğinde eski ve verimsiz planların korunmasına yol açabilir.

10. Gözlemlenebilirlik geliştirmeleri

PostgreSQL 19 yeni izleme alanları getiriyor:

• pg_stat_lock: Lock türüne göre istatistikler
• pg_stat_recovery: Recovery süreci hakkında ayrıntılı görünürlük
• Statistics view’larında stats_reset
• Vacuum ve analyze progress ekranlarında işlemi başlatan kaynağın gösterilmesi
• pg_stat_progress_vacuum içinde çalışma modu
• EXPLAIN ANALYZE için async I/O istatistiklerini gösteren IO seçeneği
• Process türüne göre log_min_messages seviyesi
• Vacuum ve analyze loglarında WAL full-page write miktarı

Bu geliştirmeler performans problemlerinin yalnızca “sorgu yavaş” düzeyinde değil; I/O, lock, recovery ve bakım operasyonu seviyesinde incelenmesini kolaylaştırabilir.

Güvenlik ve bağlantı değişiklikleri

Server Name Indication desteği

PostgreSQL 19, pg_hosts.conf dosyasıyla sunucu tarafı SNI desteği getiriyor. Aynı PostgreSQL sunucusu, istemcinin talep ettiği hostname’e göre farklı TLS sertifikaları sunabilecek. Bu özellik şu yapılarda faydalı olabilir:

• Birden fazla hostname kullanan shared cluster
• Kurum veya müşteri bazlı bağlantı alan adları
• Sertifika rotasyonu
• Çok kiracılı platformlar
• Farklı servis isimlerine göre TLS sertifikaları

SNI desteği kimlik doğrulama ve authorization yerine geçmez. Yalnızca bağlantı sırasında sunulacak TLS sertifikasının seçilmesini sağlar.

MD5 kimlik doğrulama uyarıları

PostgreSQL 18’de deprecated olarak işaretlenen MD5 authentication için PostgreSQL 19 başarılı bağlantı sonrasında istemciye uyarı gönderecek. Bu uyarı md5_password_warnings ayarıyla kontrol edilebilir. Ekipler MD5’i susturmak yerine SCRAM-SHA-256 migration planı hazırlamalıdır.

RADIUS desteği kaldırıldı

PostgreSQL 19, yalnızca UDP tabanlı ve güvenli biçimde düzeltilemeyeceği gerekçesiyle RADIUS authentication desteğini kaldırıyor. RADIUS kullanan kurumlar PostgreSQL 19 yükseltmesinden önce alternatif kimlik doğrulama yaklaşımı belirlemelidir.

PostgreSQL 19’daki önemli uyumluluk değişiklikleri

JIT’in varsayılan olarak kapatılması, çok sayıda büyük analitik sorgu çalıştıran sistemlerde performans regresyonu yaratabilir. PostgreSQL release notes, bu tür sistemlerin JIT’i manuel olarak etkinleştirmesi gerekebileceğini belirtiyor. standard_conforming_strings PostgreSQL 19 sunucusunda her zaman açık olacaktır. Daha eski pg_dump araçlarıyla ve standard_conforming_strings=off kullanılarak oluşturulan dump dosyaları PostgreSQL 19’a doğru biçimde yüklenmeyebilir. Migration sırasında PostgreSQL 19 veya daha yeni istemci araçlarının kullanılması öneriliyor.

PostgreSQL 19 Beta 2 production’da kullanılmalı mı?

Hayır. PostgreSQL projesi beta ve release candidate sürümlerinin production sistemleri veya aktif geliştirme projeleri için kullanılmamasını güçlü biçimde öneriyor. Nedenleri:

• Ciddi hatalar bulunabilir.
• API ve davranışlar değişebilir.
• Özellikler geri alınabilir.
• Beta sürümler arasında migration gerekebilir.
• Extension ve driver uyumluluğu tamamlanmamış olabilir.
• Operasyon araçları henüz destek vermeyebilir.
• Production backup ve recovery süreçleri doğrulanmamış olabilir.

PostgreSQL 19 Beta 2’ye önceki herhangi bir PostgreSQL sürümünden geçmek için normal major version migration yaklaşımı gerekir:

• pg_upgrade
• pg_dump / pg_restore
• Logical replication

Veri dizinini doğrudan yeni sürümle açmak desteklenen bir yükseltme yöntemi değildir.

Kimler şimdi test etmeli?

Yüksek öncelik

• PostgreSQL 19’a ilk altı ay içinde geçmeyi planlayanlar
• Kendi PostgreSQL extension’ını geliştirenler
• ORM, driver veya database tooling geliştirenler
• Logical replication kullanan sistemler
• Büyük tablolar ve vacuum problemi yaşayanlar
• Replica üzerinden yoğun okuma yapan uygulamalar
• Temporal veri modeli kullananlar
• Property graph ihtiyacı bulunan projeler
• Checksum’ları kesintisiz etkinleştirmek isteyen ekipler
• RADIUS veya MD5 authentication kullanan kurumlar
• PostgreSQL 19 uyumluluğu sunması gereken SaaS ve hosting ürünleri

Beta testleri özellikle PostgreSQL’e bağlı platform, driver, araç ve utility geliştiricileri için önemlidir. PostgreSQL projesi bu ekiplerin yeni sürüm değişikliklerine hazırlanmak için beta dönemini kullanmasını öneriyor.

Orta öncelik

• PostgreSQL 17 veya 18 kullanan ve 2027’de yükseltme planlayan ekipler
• Yeni özellikleri araştırmak isteyen veri platformları
• Query plan regresyonlarını önceden görmek isteyenler
• Büyük major upgrade projeleri planlayan kurumlar

Şimdilik bekleyebilecekler

• Yakın dönemde major version migration planı olmayan küçük uygulamalar
• Staging veya test ortamı bulunmayan ekipler
• Kullanılan extension’ların Beta 2 desteği olmayan projeler
• Yalnızca yönetilen PostgreSQL hizmeti kullanan ve sürüm takvimini sağlayıcıya bırakanlar
• Production verisinin güvenli kopyasını üretemeyen ekipler

Beklemek, PostgreSQL 19’u tamamen görmezden gelmek anlamına gelmemelidir. En azından kullanılan driver, ORM, extension ve migration araçlarının PostgreSQL 19 planları takip edilmelidir.

Önerilen test planı

1. Mevcut sistemi envanterleyin

Kaydedilmesi gerekenler:

• PostgreSQL sürümü
• Veri tabanı büyüklüğü
• Extension’lar
• Driver’lar
• ORM
• Backup araçları
• Connection pooler
• Monitoring sistemi
• Replication yapısı
• Kritik sorgular
• Authentication yöntemi
• Locale ve encoding
• Partition yapısı

2. Production verisinin güvenli kopyasını oluşturun

Gerçekçi performans testi için production büyüklüğüne yakın veri gerekir. Ancak test ortamında:

• Kişisel veriler maskelenmeli,
• Secret’lar kaldırılmalı,
• Harici servis bağlantıları kapatılmalı,
• E-posta ve ödeme tetikleyicileri devre dışı bırakılmalıdır.

3. Ayrı bir PostgreSQL 19 Beta 2 cluster’ı kurun

Mevcut veri dizini üzerinde çalışmayın. Beta ortamı:

• Ayrı data directory
• Ayrı port
• Ayrı backup
• Ayrı monitoring
• Kolayca silinip yeniden kurulabilir yapı

kullanmalıdır.

4. Migration yöntemini test edin

Uygulamanız için planlanan gerçek migration yöntemini kullanın:

• pg_upgrade
• Dump ve restore
• Logical replication

Migration süresini, disk ihtiyacını, downtime süresini ve rollback planını ölçün.

5. Extension uyumluluğunu kontrol edin

Her extension için:

• PostgreSQL 19 desteği
• Derleme durumu
• Upgrade script’i
• Binary paket
• Backup ve restore davranışı
• Replication uyumu

kontrol edilmelidir. Bir extension’ın PostgreSQL 19 üzerinde derlenmesi, bütün fonksiyonlarının doğru çalıştığını garanti etmez.

6. Uygulama testlerini çalıştırın

• Unit test
• Integration test
• Migration test
• Transaction test
• Concurrency test
• Failover test
• Backup ve restore
• Connection pool
• Timeout davranışı
• ORM schema generation

7. Query plan karşılaştırması yapın

PostgreSQL 18 ve PostgreSQL 19 üzerinde: EXPLAIN (ANALYZE, BUFFERS, WAL)

SELECT ...;

çıktılarını karşılaştırın. Kontrol edilmesi gerekenler:

• Execution time
• Planning time
• Index kullanımı
• Join sırası
• Incremental sort
• Parallel worker
• Temp file
• Buffer hit/read
• WAL üretimi
• JIT davranışı

JIT PostgreSQL 19’da varsayılan kapalı olduğu için analitik workload’larda jit=on ve jit=off sonuçları ayrı test edilmelidir.

8. Operasyon testlerini yapın

• Backup
• Point-in-time recovery
• Physical replication
• Logical replication
• Failover
• Checksum
• Vacuum
• Repack
• Monitoring
• Alert
• Connection saturation
• Disk doluluğu

9. Açık sorunları takip edin

PostgreSQL 19 için açık maddeler herkese açık wiki sayfasında izleniyor. Test sonucunda bulunan hatalar PostgreSQL bug reporting sistemi üzerinden paylaşılabilir.

10. Beta ortamını production’a dönüştürmeyin

Kararlı sürüm yayımlandığında dahi beta cluster’ını doğrudan production olarak kullanmak yerine temiz bir migration ve doğrulama süreci planlanmalıdır.

Test kontrol listesi

Kurulum ve migration

• PostgreSQL 19 Beta 2 ayrı ortamda kuruldu mu?
• Production data directory doğrudan kullanılmadı mı?
• pg_upgrade veya dump/restore testi yapıldı mı?
• Migration süresi ölçüldü mü?
• Rollback yöntemi doğrulandı mı?
• PostgreSQL 19 istemci araçları kullanıldı mı?

Uygulama uyumluluğu

• Driver PostgreSQL 19 ile test edildi mi?
• ORM migration’ları çalıştı mı?
• Connection pooler uyumlu mu?
• Extension’lar derleniyor ve çalışıyor mu?
• Prepared statement’lar test edildi mi?
• JSON sonuç değişiklikleri kontrol edildi mi?
• postgres_fdw read-only davranışı test edildi mi?

Performans

• Kritik sorgular karşılaştırıldı mı?
• JIT açık ve kapalı test edildi mi?
• Insert performansı gerçek foreign key yapısıyla ölçüldü mü?
• Autovacuum davranışı incelendi mi?
• REPACK disk ve WAL maliyeti ölçüldü mü?
• Replica lag ölçüldü mü?
• Online checksum etkisi test edildi mi?

Operasyon

• Backup alındı mı?
• Restore testi yapıldı mı?
• Failover test edildi mi?
• Logical replication sequence senkronizasyonu doğrulandı mı?
• Monitoring sorguları güncellendi mi?
• Yeni statistics view’ları dashboard’a eklendi mi?
• Authentication değişiklikleri test edildi mi?

Yeni özellikler

• Temporal FOR PORTION OF işlemleri test edildi mi?
• Property graph sorguları gerçek veri modeliyle denendi mi?
• WAIT FOR timeout ve promotion senaryosu test edildi mi?
• pg_plan_advice plan değişiklikleri değerlendirildi mi?
• REPACK CONCURRENTLY lock davranışı ölçüldü mü?

InoviqLab teknik değerlendirmesi

Bu bölüm InoviqLab’ın teknik değerlendirmesidir; resmî PostgreSQL belgelerindeki doğrulanmış bilgilerden ayrıdır. PostgreSQL 19 Beta 2’yi test etmek için en güçlü neden yeni özellikleri hemen kullanmak değildir. Asıl değer, PostgreSQL 19’a geçiş sırasında karşılaşılacak uyumsuzlukları production takviminden önce görebilmektir. Bir major version migration’ın en riskli alanları genellikle şunlardır:

• Extension uyumluluğu
• Query plan değişiklikleri
• Authentication
• Backup ve restore araçları
• Replication
• ORM davranışları
• Operasyon script’leri
• Monitoring sorguları

Bu alanlar final sürüm yayımlandıktan sonra ilk kez test edilirse migration projesi gereksiz biçimde uzar. İkinci önemli nokta, PostgreSQL 19’un yalnızca yeni SQL özelliklerinden oluşmamasıdır. JIT’in varsayılan olarak kapanması, RADIUS desteğinin kaldırılması ve standard_conforming_strings davranışının değişmesi gibi uyumluluk kararları bazı sistemlerde property graph veya temporal tablolardan daha önemli olabilir. Üçüncü nokta, resmî performans iddialarının kendi workload’unuzda yeniden ölçülmesi gerektiğidir. PostgreSQL projesi foreign key kontrolleri bulunan insert işlemlerinde iki kata kadar performans iyileşmesi bildiriyor. Bu sonuç değerli bir sinyaldir; fakat tablo yapısı, index’ler, foreign key sayısı, transaction büyüklüğü ve donanım farklı olduğunda aynı oran beklenmemelidir. Dördüncü nokta, REPACK, online checksum ve parallel autovacuum gibi “çevrim içi” özelliklerin maliyetsiz olduğu varsayılmamalıdır. Çevrim içi işlem:

• Kesinti gerektirmeyebilir,
• Fakat CPU tüketebilir,
• Disk I/O oluşturabilir,
• WAL büyütebilir,
• Replica lag yaratabilir,
• Backup penceresini etkileyebilir.

Bu nedenle “online” kelimesi “production’da testsiz uygulanabilir” anlamına gelmez. Beşinci nokta, PostgreSQL 19 testinin yalnızca veri tabanı yöneticisinin görevi olmamasıdır. Başarılı test süreci şu ekipleri birlikte kapsamalıdır:

• Backend
• DevOps
• DBA
• QA
• Güvenlik
• Veri ekibi
• Ürün operasyonu

Çünkü major version değişikliği yalnızca database engine’i değil, uygulamanın bağlantı, sorgu, migration ve operasyon davranışını da etkiler.

Sonuç

PostgreSQL 19 Beta 2 production için hazır değildir; ancak doğru ekipler için test edilmeye hazırdır. Şimdi test etmesi gerekenler:

• Yakın dönemde PostgreSQL 19’a geçmeyi planlayanlar
• Logical replication kullananlar
• Extension veya driver geliştirenler
• Büyük tablo ve bakım problemi yaşayanlar
• Replica tutarlılığı ihtiyacı bulunanlar
• Temporal veya graph veri modeli araştıranlar
• Authentication ve checksum yapılarını modernize edenler

Beklemesi gerekenler:

• Test ortamı bulunmayanlar
• Production verisini güvenli biçimde çoğaltamayanlar
• Yakın dönemde major upgrade planlamayanlar
• Extension ekosistemi henüz hazır olmayan projeler

PostgreSQL 19 Beta 2’nin en doğru kullanım alanı yeni bir production sistemi başlatmak değil; gelecekteki major version migration’ın risklerini bugünden ölçmektir.