PostgreSQL 19 bu ayın içinde genel kullanıma açılması beklenen bir sürüm; 24 Eylül 2026'da dördüncü beta yayınlandı, ardından ekim başında sürüm adayı planlanıyor. Bizim ilgimizi çeken taraf parlak yeni özellikler değil, yıllardır bakım penceresi ayarlamaya harcadığımız saatleri azaltacak olan kısım.
REPACK: tablo şişmesine yerleşik cevap
Yoğun güncelleme alan tablolarda ölü satırların şişme (bloat) yaratması klasik bir sorun. Çözüm uzun süredir ya VACUUM FULL ile tabloyu kilitlemek ya da harici pg_repack aracını kurmaktı. PostgreSQL 19 ile REPACK çekirdeğe giriyor; beta 4'te çökme ve izin düzeltmeleri de aldı.
Sahada bunun anlamı şu: araç takip veya sipariş durumu gibi sürekli güncellenen tablolar için artık ek bir uzantı kurmadan, üretimi durdurmadan yeniden paketleme yapabileceksiniz. Ama yanlış anlaşılmasın — bu, indeks tasarımının ve makul bir veri saklama politikasının yerine geçmiyor.
Yeni autovacuum puanlama sistemi
Sürümde daha az konuşulan ama günlük hayatı daha çok etkileyen değişiklik autovacuum'un yeni puanlama sistemi. Eski eşik tabanlı mantık, büyük ve küçük tablolara aynı gözle bakıyordu; sonuç olarak ya çok sık ya da çok geç tetikleniyordu. Yeni yaklaşım tabloları önceliklendirdiği için, "büyük tablo aylarca vakumlanmadı" tipi sürprizlerin azalmasını bekliyoruz.
Yine de bizim tavsiyemiz değişmiyor: autovacuum ayarlarını tablo bazında değerlendirin. En çok yazılan üç tabloya özel autovacuum_vacuum_scale_factor vermek, sunucu geneli ayarları kurcalamaktan daha güvenli.
Diğer somut kazanımlar
- WAIT FOR komutunda kilitlenme ve izolasyon seviyesi hata raporlaması iyileştirildi.
- CREATE PUBLICATION ... EXCEPT ile mantıksal replikasyonda tablo hariç tutmak kolaylaştı; büyük şemalarda yazması çok daha kısa.
- COPY FROM için SIMD optimizasyonu; toplu veri yükleme işlerinde ölçülebilir hızlanma.
- Yabancı anahtar kontrollerinde performans iyileştirmeleri.
Beklenirken: geri çekilen özellikler
Dürüst bir not: beta sürecinde bazı özellikler istikrar adına geri çekildi. SQL/PGQ (graf sorguları), veri sağlama toplamlarının çevrimiçi açılıp kapatılması, FOR PORTION OF ile zamansal güncelleme/silme ve ALTER TABLE ... MERGE/SPLIT PARTITIONS bu sürümde yok. Eğer yol haritanızı bunlardan birine bağladıysanız, planı gözden geçirme zamanı.
Bu geri çekmeleri bir kusur olarak değil, topluluğun öngörülebilirlik disiplini olarak okuyoruz. Kurumsal bir veritabanında "belki çalışır" bir özellik, hiç olmamasından daha kötüdür.
Yükseltme yaklaşımımız
Ana sürüm yükseltmelerinde acele etmiyoruz. Tipik planımız: GA'dan sonra en az bir yama sürümü beklemek, kopya veri üzerinde pg_upgrade provası yapmak, uzantı uyumluluğunu (özellikle PostGIS ve pgvector) önceden doğrulamak ve yükseltme sonrası ilk iş olarak ANALYZE çalıştırmak. Son madde ihmal edildiğinde, yükseltme sonrası "her şey yavaşladı" şikâyeti neredeyse garanti.
Şişme sorununu ölçmeden çözmeye çalışmayın
REPACK'in çekirdeğe girmesi güzel, ama bir tabloyu yeniden paketlemeye karar vermeden önce şişmenin gerçekten var olduğunu ölçmek gerekiyor. Sık gördüğümüz durum, ekibin "tablo büyük" gözlemini "tablo şişmiş" sonucuna atlaması. İkisi farklı: büyük tablo normal olabilir, şişmiş tablo ise ölü satırların disk ve önbellek harcaması demek.
Pratik yaklaşımımız, ölü satır oranını ve son otomatik vakum zamanını izleyen basit bir sorguyu izleme panosuna koymak. Bu iki sayı, bakım kararını tahmine değil veriye bağlıyor. Bir de şu: şişmenin kaynağı çoğu zaman yazma deseni. Her istekte bir satırı güncelleyen sayaç mantığı (örneğin "son görülme zamanı"), tek başına devasa şişme üretebiliyor. Böyle alanları ayrı bir tabloya çıkarmak veya güncelleme sıklığını azaltmak, herhangi bir bakım komutundan daha kalıcı bir çözüm.
Mantıksal replikasyon artık daha kullanışlı
Rapor yükünü ana veritabanından ayırmak isteyen ekipler için CREATE PUBLICATION ... EXCEPT gerçek bir kolaylık. Önceden yüz tablolu bir şemadan üç tanesini hariç tutmak, doksan yedi tabloyu elle yazmak anlamına geliyordu — ve şemaya yeni tablo eklendiğinde yayını güncellemeyi unutmak klasik bir hataydı. Artık kural tersine kurulabiliyor, bu da yeni tabloların otomatik dahil olması demek.
Veritabanınız büyüdükçe bakım işleri elle taşınamaz hale geliyorsa veya yükseltme planı çıkarmak istiyorsanız, iletişim sayfamızdan bize yazın. 500'ün üzerinde projede öğrendiğimiz şey şu: veritabanı bakımı, ertelendiği sürece faiz işleyen tek teknik borç türü.