PostgreSQL 19 beta turu: property graph'ler, zamansal düzenlemeler ve daha akıllı bir upsert

PostgreSQL 19 genel kullanıma yaklaşıyor

PostgreSQL 19 beta aşamasında ve genel kullanıma sunulmasının Eylül ya da Ekim 2026 civarında bekleniyor. Hacker News'in ana sayfasında öne çıkan, VictoriaMetrics blogunda yayınlanan uygulamalı tur, geliştiricilere gelecek olan yeniliklerin pratik bir önizlemesini sunuyor. Yazı, sürüm notlarını özetlemek yerine, seçilen maddeleri çalıştırılabilir örneklere dönüştürüyor; tüm örnekler — 13 Ağustos 2026'da yayınlanan — PostgreSQL 19 beta 3 üzerinde çalıştırılmış ve her özelliğin yanında sunucunun yazdırdığı çıktı gösterilmiş. Tur, resmi sürüm notları ve PostgreSQL kaynak koduna dayanıyor ve onları tamamlayan bir eşlikçi olarak sunuluyor; kapsamlı bir katalog olarak değil.

Property graph'ler öne çıkan özellik

VictoriaMetrics yazısına göre sürümün merkezinde, SQL:2023 standardının property graph kısmı olan SQL/PGQ yer alıyor. CREATE PROPERTY GRAPH ifadesi, sıradan tabloların üzerine — bir kısmı vertex tablosu, bir kısmı edge tablosu olarak işaretlenmiş — herhangi bir veri kopyalamadan bir graf tanımı yerleştiriyor; graf, mevcut satırlar üzerinde görünüm benzeri bir nesne. Sorgular daha sonra GRAPH_TABLE ile MATCH örüntüleri kullanıyor; yönlü bir edge satır içinde yazıldığı için geçiş soruları elle yazılan join'ler yerine örüntü eşleşmelerine dönüşüyor.

Fayda, çok adımlı örüntülerle birlikte büyüyor: iki edge'i zincirlemek, bir self-join'e gerek kalmadan arkadaşların arkadaşları tarzı bir soruyu yanıtlıyor ve adsız bir vertex, ara düğümler için joker karakter işlevi görüyor. Özellikle dikkat çekici olan, işin içinde yeni bir yürütme motorunun olmaması — GRAPH_TABLE düz bir ilişkisel sorguya dönüştürülüyor; dolayısıyla geliştiricilerin zaten güven duyduğu planner, istatistikler ve index seçimleri geçerliliğini koruyor. Yazıdaki örnek plan, örüntünün sıradan hash join'lere çözüldüğünü gösteriyor.

Özel bir graf veritabanından geçmek isteyenler içinse bir uyarı var: bu ilk uygulama değişken uzunluklu path'leri desteklemiyor. Belirli bir adım aralığını ifade eden nicelik belirteçleri ayrıştırılıyor ancak "element pattern quantifier is not supported" hatasıyla reddediliyor; bu yüzden bir örüntüdeki her adımın açıkça yazılması gerekiyor. Özellik, sürüm notlarında Peter Eisentraut ve Ashutosh Bapat'a atfediliyor.

Zamansal güncelleme ve silme işlemleri satırları otomatik bölüyor

İkinci bir ek, bir range sütununun bir dilimine UPDATE ve DELETE uygulayan FOR PORTION OF ifadesi. Geliştirici, tüm bir geçerlilik dönemini elle yeniden yazmak yerine bir alt dönem belirtiyor ve ameliyatı PostgreSQL yapıyor. Yazının örneğinde, 2026'nın tamamı için geçerli bir fiyat tutan tek satır, sadece Temmuz'a ait bir fiyat değişikliğinden sonra üç satıra dönüşüyor: güncellenen ay ve iki yanındaki dokunulmamış dönemler. DELETE bölmek yerine kırpıyor ve NULL bir sınır sonsuz anlamına geliyor; böylece "Aralık'tan itibaren" bir dönemi kaldırmak önceki kısmı olduğu gibi bırakıyor. Özellik, zamansal tablolar üzerine yeni bir dokümantasyon bölümüyle birlikte geliyor ve Paul A. Jungwirth'e atfediliyor.

Upsert artık çakıştığı satırları bildirebiliyor

INSERT ... ON CONFLICT DO NOTHING ... RETURNING her zaman kör bir noktaya sahip oldu: çakışan satırlar sonuçta hiç görünmüyordu ve bu da "zaten mevcut" ile "hiç işlenmemiş" durumlarını ayırt edilemez kılıyordu. PostgreSQL 19, mevcut satırları onlara yazmadan döndüren ON CONFLICT DO SELECT ifadesini ekliyor — demoda, zaten var olan bir widget'ı ekleme girişimi, deneneni değil kayıtlı miktarı bildiriyor. İfade ayrıca bir kilitleme ifadesi de kabul ediyor; böylece FOR UPDATE, uygulama sıradaki adımı ne olacağına karar verirken çakışan satırları tutabiliyor; kilitleme bir satırın xmax değerini damgaladığı için, yazıya göre xmax = 0 kontrolü gerçekten eklenen satırlarla zaten orada olanları ayırt ediyor.

Neden önemli

Çekirdek PostgreSQL'deki SQL/PGQ, graf tarzı sorgulamayı ayrı bir graf veritabanı gerektirmeden standart ilişkisel motora taşıyor — yine de eksik değişken uzunluklu path'ler yüzünden graf depolarının tam bir yerine geçmiyor. Zamansal işlem, geçerlilik dönemlerini izleyen uygulamaların uzun süredir elle yaptığı kayıt tutma yükünü ortadan kaldırıyor ve DO SELECT, upsert akışlarındaki uzun süredir süren kullanılabilirlik açığını kapatıyor. Genel kullanıma sunulmanın 2026 sonbaharında beklenmesiyle, betayı şimdi — betalar üretime hazır olmadığından atılabilir bir ortamda — denemek, ekiplere yükseltmeleri planlamak ve hangi özelliklerin erken geçişi haklı çıkardığını değerlendirmek için zaman tanıyor.