PostgreSQL 19 Geliyor: Yenilikler ve Upgrade Planı

PostgreSQL 19, 13 Ağustos 2026'da yayınlanan Beta 3 ile birlikte hâlâ beta aşamasında ilerliyor; aynı duyuruda 18.6, 17.11, 16.15, 15.19 ve 14.24 güvenlik yamaları da çıktı. Bu yazıda PostgreSQL 19'un 23 Eylül 2026 itibarıyla gerçek durumunu, hangi özelliklerin beta sürecinde geri çekildiğini ve production'daki 18.x kurulumunu 19'a taşırken izleyeceğin somut planı bulacaksın.

💡 Pro Tip: PostgreSQL 19 hâlâ GA değilken önce 18.6 güvenlik yamasını üretime al — 19 upgrade planı beklerken açık kapı bırakma.

İçindekiler

• PG 19 takvimi ve beta durumu
• Öne çıkan yenilikler ve neyi hızlandırıyor
• Kalıcı özellikler
• Geri çekilen özellikler (Eylül 2026 revert dalgası)
• 18.6 yama seti ve kapatılan açıklar — önce yamayı geç
• Uygulama katmanı etkisi (Prisma/Drizzle sürücü uyumu)
• pg_upgrade ile kesinti planı ve geri alma
• Extension envanteri çıkarma (upgrade'i asıl bloke eden şey)
• Ne zaman beklemeli, ne zaman geçmeli
• Yedek + restore provası olmadan upgrade yok
• SSS
• PostgreSQL 19'da neler yeni?
• PostgreSQL 18'den 19'a nasıl upgrade edilir?
• PostgreSQL 19 ne zaman GA olacak?
• Prisma PostgreSQL 19'u destekliyor mu?
• btree_gist kullanıyorsam ne değişiyor?
• RADIUS authentication kullanıyorsam ne yapmalıyım?
• Sonuç
• Kaynaklar

PG 19 takvimi ve beta durumu

PostgreSQL Global Development Group, 13 Ağustos 2026'da PostgreSQL 19'un üçüncü beta sürümünü yayınladı. Resmî duyuru bu sürümü "the third beta release of PostgreSQL 19" olarak tanımlıyor ve aynı pakette 28 güvenlik açığının ve 110'dan fazla hatanın düzeltildiğini belirtiyor.

Resmî roadmap sayfası PostgreSQL 19'u "planned for September 2026" diye tarifliyor, ama kesin bir RC1 veya GA tarihi vermiyor. 23 Eylül 2026 itibarıyla PostgreSQL 19 Open Items sayfasındaki "Important Dates" tablosu Beta 4'ü 24 Eylül 2026 olarak veriyor; aynı tabloda RC 1 ve GA satırları hâlâ "TBD" (belirlenecek) durumda. Commit freeze'in 19 Eylül'de planlandığı ve "Ekim sonuna kadar GA" hedefi ise topluluk kaynağından (thebuild.com'daki katkıcı blog yazısı) geliyor — bu resmî bir taahhüt değil.

Aynı gün beş stabil sürüm de yamalandı: PostgreSQL 19 Beta 3 duyurusu yalnız kendi sürümünü değil, desteklenen beş major sürümün (18, 17, 16, 15, 14) güvenlik yamalarını da aynı tarihte yayınladı — proje, beta bir sürümü hazırlarken bile stabil sürümlerin güvenlik bakımını aksatmıyor. Aşağıdaki "18.6 yama seti" bölümü bu paketi ayrıntılı anlatıyor.

Bu makalenin yayın tarihi olan 14 Ekim 2026 itibarıyla PostgreSQL 19'un GA olmuş olması garanti değildir. Aşağıdaki tüm bölümler beta sürecindeki mevcut davranışı anlatır; production'a geçmeden önce sürümün gerçek durumunu postgresql.org'dan teyit et.

Öne çıkan yenilikler ve neyi hızlandırıyor

Kalıcı özellikler

• REPACK / REPACK (CONCURRENTLY): VACUUM FULL ile CLUSTER'ın işlevini birleştiren yeni bir komut. CONCURRENTLY bağımsız bir anahtar kelime değil, parantezli seçenek listesinde verilen bir seçenek (REPACK [ ( option [, ...] ) ] ...). Seçenek verilmeden çalıştırıldığında tabloda ACCESS EXCLUSIVE kilit alınır ve bu, tablo üzerindeki tüm diğer veritabanı işlemlerini engeller — bu yüzden production'da (CONCURRENTLY) varyantı tercih edilmeli.
• ON CONFLICT DO SELECT ... RETURNING: upsert sonrası çakışan satırı da RETURNING ile geri döndürebiliyor.
• Pencere fonksiyonlarında IGNORE NULLS: LAG/LEAD gibi fonksiyonlarda NULL değerleri atlayarak bir önceki/sonraki gerçek değeri bulmayı kolaylaştırıyor.
• Mantıksal replikasyonda sequence desteği: Logical replication artık sequence değerlerini de replike ediyor; release notes bunun CREATE SUBSCRIPTION, ALTER SUBSCRIPTION ... REFRESH PUBLICATION ve ALTER SUBSCRIPTION ... REFRESH SEQUENCES komutlarıyla etkinleştiğini yazıyor.
• Autovacuum'da paralel index vacuum + skorlama: Autovacuum artık bir tablonun indekslerini paralel worker process'lerle vacuum edebiliyor; hangi tablonun önce vacuum edileceğine karar veren yeni bir skorlama sistemi eklendi.
• WAIT FOR: standby'ın belirli bir LSN'e kadar replay etmesini bekleyen yeni komut; "read-your-writes" deseni için kullanılabiliyor.
• default_toast_compression artık lz4: büyük alan sıkıştırmasında varsayılan algoritma değişti.

Geri çekilen özellikler (Eylül 2026 revert dalgası)

Beta 3'ten (13 Ağustos) bu yana, GA öncesi olgunlaşmamış bulunan birkaç büyük özellik PostgreSQL 19'un kararlı geliştirme dalından geri çekildi:

• SQL/PGQ (property graph sorguları — CREATE PROPERTY GRAPH komutu ve ilişkili graph-sorgu sözdizimi) — 7 Eylül'de 47 commit geri alındı. Gerekçe, sürüm sonrası bug riskiydi; hangi sürümde geri döneceği belirsiz, çünkü yalnız 19 dalından değil geliştirme dalından da çıkarıldı.
• FOR PORTION OF (temporal UPDATE/DELETE) — 15 Eylül'de geri çekildi; bu da hem 19 dalından hem geliştirme dalından.
• pg_get_role_ddl(), pg_get_tablespace_ddl(), pg_get_database_ddl() — 12 Eylül'de yalnız 19 dalından geri çekildi; PostgreSQL 20 hedefiyle geliştirme dalında duruyor.
• Çevrimiçi data checksum açma/kapama — 16 Eylül'de 19 dalından geri çekildi; yalnızca master'da (PostgreSQL 20 hedefli) yaşamaya devam ediyor.
• MERGE PARTITIONS zaten daha önce bir sonraki sürüme ertelenmişti.

Yani "PostgreSQL 19'da graph sorguları var" diyen bir kaynak görürsen, o kaynak muhtemelen Beta 1/2 anlık görüntüsünde donmuş — 23 Eylül 2026 itibarıyla bu özellik PostgreSQL 19'da yok. Resmî release notes sayfası da bu revert'leri henüz yansıtmıyor; sayfanın başında "Release date: 2026-??-??, AS OF 2026-07-18" yazıyor — liste 18 Temmuz 2026 anlık görüntüsü.

REPACK (CONCURRENTLY) çevrimiçi bakım için pratikte şöyle çalışıyor — dikkat et, seçenek parantez içinde veriliyor:

1-- CONCURRENTLY parantezli bir seçenek: REPACK [ ( option [, ...] ) ] tablo
2-- Yeniden yazma boyunca tablo erişilebilir kalır; ACCESS EXCLUSIVE kilit
3-- yalnızca tablo ve indeks dosyalarının takası için, kısa süreliğine alınır.
4REPACK (CONCURRENTLY) orders;
5 
6-- Kilitleme kabul edilebiliyorsa (bakım penceresinde), daha hızlı:
7REPACK orders;

18.6 yama seti ve kapatılan açıklar — önce yamayı geç

13 Ağustos 2026 duyurusu yalnız 19 Beta 3'ü değil, desteklenen tüm major sürümler için güvenlik yamalarını da getirdi: 18.6, 17.11, 16.15, 15.19 ve 14.24. Toplamda 28 güvenlik açığı ve 110'dan fazla hata düzeltildi. Öne çıkan CVE'ler:

• CVE-2026-6471 — logical decoding'deki eksik yetki kontrolü, REPLICATION yetkisi olan süper-kullanıcı olmayan bir rolün, seçtiği logical decoding eklentisi üzerinden sunucuyu çalıştıran işletim sistemi hesabının gördüğü herhangi bir dosyayı dlopen etmesine izin veriyordu (CVSS 7.2).
• CVE-2026-14663 — pgcrypto, OpenSSL tarafından devre dışı bırakılmış cipher'larda sessizce düz metne şifreliyor ve düz metinden çözüyordu; hangi cipher'ların devre dışı olduğunu OpenSSL sürümü ve konfigürasyonu belirliyor. Resmî CVE kaydının ifadesiyle kullanıcı "via direct observation of the faulty ciphertext" düz metni geri elde edebiliyor; üstelik uygulama şifreli veriyi girdi olarak kabul ediyorsa yanlış anahtarla bile çözme işlemi başarılı oluyor ve Modification Detection Code'un (MDC) sağladığı mütevazı koruma da kayboluyor.
• CVE-2026-6464 — psql'de COPY FROM STDIN erken başarısız olduğunda, veri satırları psql komutu olarak işlenebiliyordu (CVSS 8.1).

Eğer hâlâ PostgreSQL 18.x, 17.x, 16.x, 15.x veya 14.x çalıştırıyorsan, PostgreSQL 19'u beklemeden önce bu yama setini uygulaman gerekiyor — bunlar 19'un yeniliği değil, mevcut production'unun açık kapıları.

Ayrıca aynı duyuru bir tarih uyarısı da içeriyor: PostgreSQL 14, 12 Kasım 2026'da yama almayı bırakacak. Hâlâ PostgreSQL 14 kullanıyorsan, 19'a geçiş planını bu tarihe göre önceliklendir.

Uygulama katmanı etkisi (Prisma/Drizzle sürücü uyumu)

PostgreSQL 19 release notes'unda wire protokolünde kırıcı bir değişiklik listelenmiyor; bu yüzden pg, postgres.js, Drizzle gibi düşük seviye sürücüler çoğu zaman ek bir güncelleme gerektirmeden yeni major sürümle konuşabiliyor. Ama bunu "resmi destek" ile karıştırma.

Prisma tarafında dikkat edilmesi gereken nokta şu: Prisma'nın "supported databases" sayfası PostgreSQL için sürüm bazlı bir uyumluluk listesi vermiyor. Sayfa PostgreSQL'i (Prisma Postgres dâhil) @prisma/orm-postgres paketiyle "Release candidate" statüsünde gösteriyor ve bağlantının standart bir connection string üzerinden kurulduğunu söylüyor. Yani "PostgreSQL 19 destekleniyor mu?" sorusunun cevabını bu sayfadan bir sürüm numarası okuyarak alamazsın — sayfanın o anki hâlini kendin kontrol etmen gerekiyor.

Pratik öneri: PostgreSQL 19 hâlâ beta iken production ORM'ini buna bağlama. Staging'de deneyeceksen, önce Prisma/Drizzle'ın güncel "supported databases" sayfasını kontrol et; wire protokolünde kırıcı bir değişiklik yoksa sürücü seviyesinde sorun beklenmez, ama bunu "garantili destekleniyor" diye sunma.

Kısacası: Prisma ORM 7 ve öncesinde schema.prisma içindeki datasource bloğu ve provider = "postgresql" satırı değişmez; Prisma ORM 8'de ise şema dosyasının adı contract oldu ve dokümantasyonun ifadesiyle "it has no datasource or generator blocks because the connection string lives in prisma.config.ts" — her iki durumda da PostgreSQL 19'a geçişte değişen tek şey connection string'in işaret ettiği sunucu.

pg_upgrade ile kesinti planı ve geri alma

PostgreSQL 19'a geçerken standart yol yine pg_upgrade; alternatif olarak pg_dumpall ile dump/restore ya da mantıksal replikasyon kullanılabiliyor. Ama önce bilmen gereken breaking change'ler var:

• standard_conforming_strings artık her zaman on. PostgreSQL 19 öncesi pg_dump çıktıları standard_conforming_strings = off ile alınmışsa, bu dump'lar 19'a düzgün yüklenmeyebiliyor. Eski dump'ları elden geçirmeden restore etme.
• Veritabanı, rol ve tablespace adlarında CR/LF (satır sonu karakterleri) artık yasak. pg_upgrade, bu tür isimleri taşıyan cluster'ları yükseltmeyi doğrudan reddediyor; değişikliğin gerekçesi güvenlik.
• RADIUS authentication tamamen kaldırıldı — yalnızca UDP üzerinden çalışan implementasyon "düzeltilemez derecede güvensiz" bulunduğu için sökülmüş. pg_hba.conf'ta RADIUS kullanıyorsan upgrade öncesi başka bir auth yöntemine geçmelisin.
• JIT artık varsayılan olarak kapalı. Release notes gerekçeyi açık yazıyor: maliyet modeli güvenilir bulunmadı ("this costing has been determined to be unreliable"). Büyük analitik sorgular çalıştıran kurulumların JIT'i elle açması gerekiyor (jit = on).
• MD5 parola kimlik doğrulaması artık her başarılı girişte uyarı basıyor (md5_password_warnings ile kontrol ediliyor). MD5 PostgreSQL 18'de deprecate edilmişti; scram-sha-256'ya geçmek için iyi bir sebep.
• max_locks_per_transaction varsayılanı 64'ten 128'e çıktı — ama bu ek pay değil. Release notes birebir şöyle diyor: "Lock size allocation has changed, so effectively settings must now be doubled to match their capacity in previous releases." Yani PG ≤18'de bu değeri elle ayarladıysan, aynı kapasiteyi korumak için değerini ikiye katlaman gerekiyor (256 ayarlamışsan 512).

Kesinti planı şu adımları izlemeli:

1# 1) Kuru deneme — gerçek veriye dokunmadan uyumluluk kontrolü
2pg_upgrade \
3  --old-datadir=/var/lib/postgresql/18/main \
4  --new-datadir=/var/lib/postgresql/19/main \
5  --old-bindir=/usr/lib/postgresql/18/bin \
6  --new-bindir=/usr/lib/postgresql/19/bin \
7  --check
8 
9# 2) Gerçek yükseltme (--link ile disk alanı ve süre tasarrufu,
10#    ama eski data dizinini geri dönüş garantisi olarak SAKLA)
11pg_upgrade \
12  --old-datadir=/var/lib/postgresql/18/main \
13  --new-datadir=/var/lib/postgresql/19/main \
14  --old-bindir=/usr/lib/postgresql/18/bin \
15  --new-bindir=/usr/lib/postgresql/19/bin \
16  --link
17 
18# 3) pg_upgrade post-upgrade işi gerektiren bir şey bulursa uyarı basar ve
19#    .sql script'leri üretir; adlarını kendi çıktısında verir. Dokümantasyon
20#    bu script'lerin nasıl çalıştırılacağını birebir yazıyor:
21#    "Each script should be run using: psql --username=postgres --file=script.sql postgres"
22psql --username=postgres --file=update_extensions.sql postgres

Geri alma planı basit ama disipline bağlı: --link modunda eski data dizinini upgrade tamamlanır tamamlanmaz silme; en az bir doğrulama döngüsü (smoke test + kritik sorgular) geçene kadar sakla. Sorun çıkarsa eski cluster'ı yeniden başlatmak, yeni cluster'ı silmekten çok daha hızlı bir kurtarma yolu.

Extension envanteri çıkarma (upgrade'i asıl bloke eden şey)

Pratikte çoğu pg_upgrade sürprizi extension'lardan çıkıyor, sürüm numarasından değil. PostgreSQL'in kendi pg_upgrade dokümantasyonu şunu açıkça belirtiyor: extension güncellemeleri mevcutsa pg_upgrade bunu raporlar ve sonradan çalıştırılabilecek bir script üretir. Bu script'i görmeden ve çalıştırmadan upgrade'i "tamamlandı" saymak, üretimde pg_extension sürümüyle gerçek şema arasında sessiz bir uyumsuzluk bırakır — sonuç genelde "fonksiyon bulunamadı" ya da beklenmeyen davranış olarak ortaya çıkar.

Upgrade'e başlamadan önce şu envanteri çıkar:

1-- Kurulu her extension'ın adı, versiyonu ve şeması
2SELECT extname, extversion, extnamespace::regnamespace AS schema
3FROM pg_extension
4ORDER BY extname;

btree_gist kullanıyorsan ayrı bir uyarı var. Değişen şey opclass'ın tanımı değil, varsayılan opclass işaretlemesi: release notes bunu "Change the default index opclasses for inet and cidr data types from btree_gist to GiST" diye özetliyor ve gerekçeyi açık yazıyor — "The btree_gist inet/cidr opclasses are broken because they can exclude rows that should be returned." Bu bozukluk REINDEX ile düzelmez, çünkü REINDEX aynı kusurlu opclass'ı yeniden kurar; dokümantasyonun ifadesiyle sorun "unfixable without redefining the contents of indexes that use these opclasses". Dolayısıyla reçete indeksi yeniden kurmak değil, değiştirmek: upgrade'den önce indeksi yerleşik inet_ops opclass'ıyla yeniden oluşturup eskisini düşürmen gerekiyor — CREATE INDEX good_index ON mytable USING GIST (addr inet_ops); ardından DROP INDEX bad_index;. Bunu yapmazsan pg_upgrade cluster'ı yükseltmeyi reddediyor ve indeksleri upgrade öncesi değiştirmeni söylüyor.

Her extension için kontrol listesi:

• Paylaşımlı kütüphane (.so) dosyası yeni major sürüm için yeniden derlenmiş mi?
• Extension'ın kendi CHANGELOG'unda PostgreSQL 19 uyumluluğu açıkça belirtilmiş mi?
• pg_upgrade --check çıktısında bu extension için bir uyarı var mı?

13 Ağustos 2026'da birlikte yamalanan sürümler ve neyi işaret ettikleri:

Ne zaman beklemeli, ne zaman geçmeli

23 Eylül 2026 itibarıyla PostgreSQL 19 hâlâ beta; RC1 ve GA tarihleri resmî olarak "TBD". PostgreSQL'in son yıllardaki yıllık kadansı (PostgreSQL 18, 25 Eylül 2025'te çıkmıştı) Eylül-Ekim aralığında bir GA'yı olası kılıyor, ama bu bir gösterge, garanti değil.

PostgreSQL'in destek politikası her major sürümü ilk çıkışından 5 yıl sonra EOL yapıyor. Örneğin PostgreSQL 18, 25 Eylül 2025'te çıktı ve 14 Kasım 2030'da EOL olacak. PostgreSQL 19 henüz GA olmadığı için kesin EOL tarihi hesaplanamaz, ama aynı 5 yıllık pencere geçerli olacak.

Yedek + restore provası olmadan upgrade yok

PostgreSQL'in kendi release notu bunu açıkça şart koşuyor: "A dump/restore using pg_dumpall or use of pg_upgrade or logical replication is required for those wishing to migrate data" — yani veri taşımak isteyen herkes için pg_dumpall ile dump/restore, pg_upgrade veya mantıksal replikasyondan biri zorunlu, "hiçbiri" seçeneği yok.

Pratikte bunun anlamı: pg_upgrade --check çıktısı temiz gelse bile, upgrade'i doğrudan production'da denemiyorsun. Sırasıyla:

1. Production'ın güncel bir dump'ını veya fiziksel kopyasını al.
2. Bu kopyayı ayrı bir staging cluster'a restore et.
3. Staging'de pg_upgrade --check, sonra gerçek upgrade'i çalıştır.
4. Uygulamanın kritik sorgularını (özellikle extension kullanan ve btree_gist indeksli tabloları) staging'de test et.
5. Ancak bu adımlar sorunsuz geçtikten sonra aynı planı production'da uygula — ve eski data dizinini doğrulama tamamlanana kadar sakla.

Restore provası atlanan bir upgrade, "denendi" değil "şansa bırakıldı" demektir.

SSS

PostgreSQL 19'da neler yeni?

23 Eylül 2026 itibarıyla öne çıkan kalıcı yenilikler: çevrimiçi tablo bakımı için yerleşik REPACK / REPACK (CONCURRENTLY) komutu, ON CONFLICT DO SELECT ... RETURNING, pencere fonksiyonlarında IGNORE NULLS, mantıksal replikasyonda sequence desteği ve autovacuum'da paralel index vacuum + skorlama. Beta sürecinde denenen SQL/PGQ (property graph sorguları) ve FOR PORTION OF (temporal UPDATE/DELETE) Eylül 2026'da geri çekildi; bu ikisi PostgreSQL 19'da yer almayacak.

PostgreSQL 18'den 19'a nasıl upgrade edilir?

Standart yol pg_upgrade (veya pg_dumpall ile dump/restore, ya da mantıksal replikasyon). Önce pg_upgrade --check ile kuru deneme yap, sonra --link ile gerçek upgrade'i çalıştır. Upgrade öncesi standard_conforming_strings her zaman on olacağını, RADIUS auth'un kaldırıldığını, max_locks_per_transaction varsayılanının 128'e çıktığını ve her extension'ın yeniden derlenmesi gerekebileceğini kontrol et.

PostgreSQL 19 ne zaman GA olacak?

23 Eylül 2026 itibarıyla kesin bir GA tarihi resmî olarak açıklanmış değil. PostgreSQL 19 Open Items sayfasındaki "Important Dates" tablosu Beta 4'ü 24 Eylül 2026 olarak veriyor, ama aynı tabloda RC 1 ve GA satırları hâlâ "TBD"; "Ekim sonuna kadar GA" yalnız topluluk kaynağında konuşulan bir hedef. Tarihsel kadans (PostgreSQL 18, Eylül 2025'te çıkmıştı) bir gösterge ama garanti değil.

Prisma PostgreSQL 19'u destekliyor mu?

Prisma'nın "supported databases" sayfası PostgreSQL için sürüm bazlı bir uyumluluk listesi içermiyor: PostgreSQL'i (Prisma Postgres dâhil) @prisma/orm-postgres paketiyle "Release candidate" statüsünde listeliyor ve standart bir connection string ile bağlandığını söylüyor. Yani sayfadan "19 destekleniyor" ya da "desteklenmiyor" diye net bir cevap çıkmıyor; production'a almadan önce sayfanın güncel hâlini kendin kontrol et. Wire protokolünde kırıcı bir değişiklik olmadığı için sürücü seviyesinde genelde sorun beklenmez, ama bunu garanti sayma.

btree_gist kullanıyorsam ne değişiyor?

PostgreSQL 19, inet ve cidr için varsayılan opclass işaretlemesini btree_gist'ten yerleşik GiST'e taşıyor; btree_gist'in inet/cidr opclass'ları döndürülmesi gereken satırları eleyebildikleri için bozuk kabul ediliyor. pg_upgrade bu indeksleri taşıyan cluster'ı yükseltmeyi reddediyor ve indeksleri upgrade öncesi değiştirmeni söylüyor. REINDEX işe yaramaz (aynı kusurlu opclass'ı yeniden kurar); doğru yol indeksi inet_ops ile yeniden oluşturup eskisini düşürmek: CREATE INDEX good_index ON mytable USING GIST (addr inet_ops); sonra DROP INDEX bad_index;.

RADIUS authentication kullanıyorsam ne yapmalıyım?

PostgreSQL 19'da RADIUS authentication tamamen kaldırıldı çünkü yalnızca UDP üzerinden çalışan implementasyon güvensiz bulundu. pg_hba.conf'unda RADIUS varsa upgrade öncesi başka bir authentication yöntemine (örneğin SCRAM) geçmelisin.

Sonuç

PostgreSQL 19, 23 Eylül 2026 itibarıyla hâlâ beta aşamasında ve kesin bir GA tarihi resmî olarak yok — Beta 3 sürecinde denenen SQL/PGQ ve FOR PORTION OF gibi büyük özellikler bile geri çekildi. Bu, "GA'yı bekle" tavsiyesinin gerçek bir gerekçesi: sürüm hâlâ şekilleniyor.

Şu an yapman gereken iki şey birbirinden bağımsız: birincisi, 19'u beklerken REST API tasarım prensiplerini gözden geçirerek veritabanı katmanının üstündeki sözleşmeyi sağlamlaştırmak, ikincisi mevcut PostgreSQL sürümünü (18.6/17.11/16.15/15.19/14.24) güncel tutmak. Eğer Supabase gibi PostgreSQL tabanlı bir platform kullanıyorsan üst sürüm geçişi genelde sağlayıcı tarafından yönetilir — bkz. Supabase Edge Functions ve Deno runtime. Drizzle ile edge-native bir kurulumun varsa Drizzle ORM + Turso/SQLite edge pattern yazısı sürücü seviyesinde neyin değiştiğini gösteriyor. Cloud SQL üzerinde PostgreSQL çalıştırıyorsan Firebase Data Connect + GraphQL + Cloud SQL entegrasyonunu gözden geçir. Vektör iş yükleri için PostgreSQL'i pgvector ile mi yoksa özel bir vektör veritabanıyla mı çalıştıracağına karar vermeden önce Pinecone/Weaviate/Qdrant karşılaştırması faydalı bir referans.

Kısacası: PostgreSQL 19'u şimdiden production planına yaz, ama "GA oldu" diyene kadar hiçbir tarihi taahhüt olarak alma.

Kaynaklar

• PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released! — resmî duyuru: 28 güvenlik açığı, 110+ hata, PostgreSQL 14 için 12 Kasım 2026 EOL uyarısı.
• PostgreSQL 19 Release Notes — özellik listesi, breaking change'ler, standard_conforming_strings ve isimlendirme kısıtları.
• PostgreSQL pg_upgrade dokümantasyonu — upgrade adımları, extension güncelleme script'i.
• PostgreSQL REPACK komutu dokümantasyonu — ACCESS EXCLUSIVE kilit davranışı, CONCURRENTLY seçeneği.
• PostgreSQL Versioning Policy — 5 yıllık destek penceresi.
• tapoueh.org — Getting Ready for PostgreSQL 19 — Eylül 2026 revert dalgasının (SQL/PGQ, FOR PORTION OF, DDL fonksiyonları, checksum toggle) güncel takibi.
• thebuild.com — 19th Nervous Breakdown — GA takvimi hakkında topluluk gözlemi, Beta 4/commit freeze planı.
• endoflife.date — PostgreSQL — sürüm/EOL tablosu referansı.