Postgres 16'ya karşı 17'ye karşı 18: önemli olan kazançlar

Üç versiyon tek bir genel performans rakamıyla birbirinden ayrılmıyor. Her biri, mimarinin belirli bir noktasını, her seferinde farklı bir hedef kitleyle düzeltir: Postgres 17 için büyük tablolar, Postgres 18 için yüksek gecikmeli depolama. Aşağıdaki tablo, her projenin ayrıntılarına girmeden önce, tümü tarihli, doğrulanabilir gerçekleri özetlemektedir.

Kaynaklar: PostgreSQL projesinin resmi sürüm notları (postgresql.org), her büyük sürümden sonra Microsoft Tech Community ve Crunchy Data tarafından yayınlanan analizlerle çapraz referanslıdır. Erişim tarihi: 24 Ağustos 2026.

Postgres 17'den önce VACUUM, temizlenecek ölü kayıtların listesini maintenance_work_memboyutunda basit bir dizide saklıyordu. Sorun hesaplamanın hızında değil, yapının kendisindeydi: Bu tablo, bunun ötesinde ne kadar yapılandırılırsa yapılandırılsın, 1 GB civarında sabitlendi. Yaklaşık 178 milyondan fazla ölü satırın bulunduğu bir tabloda, VACUUM'un birden fazla geçişte döngü yapması ve her birinin tüm dizinleri yeniden okuması gerekiyordu.

Postgres 17, bu diziyi, demet tanımlayıcılarını depolamak için gereken alanı büyük ölçüde sıkıştıran uyarlanabilir bir sayı tabanı ağacı olan TidStore adı verilen bir yapıyla değiştirir. Projenin resmi sürüm notları, eski yapıyla ilişkili yapay tavan olmadan, bazı durumlarda VACUUM tarafından kullanılan hafızanın 20 kata kadar azaldığını gösteriyor. Kaynak: PostgreSQL 17 resmi sürüm notları, postgresql.org, 26 Eylül 2024. Microsoft Tech Community ve Crunchy Data, sürümden kısa bir süre sonra bu değişikliğin teknik analizini yayınladı. Her ikisi de yüksek silme veya güncelleme oranıyla birkaç yüz milyon satırdan oluşan tablolara yönelik somut ilgiyi doğruluyor.

Bu proje temel olarak belirli bir senaryoya fayda sağlar: yüksek silme veya güncelleme oranına sahip büyük bir tablo. VACUUM, kullanılabilir bellek yetersizliği nedeniyle daha önce birkaç geçişte çalışıyordu. Küçük bir tabloda veya ağırlıklı olarak okuma yükünde kazanç marjinal kalır, hatta görünmez olur.

İkinci Postgres 17 projesi daha gizli bir noktaya değiniyor: işlem anlık görüntülerinin hesaplanması. Postgres'in MVCC görünürlük kurallarını uygulamak için her sorgunun, başka hangi işlemlerin devam ettiğini bilmesi gerekir. Çok sayıda çekirdeğe ve aktif bağlantıya sahip bir makinede bu hesaplama, paylaşılan bir iç yapı üzerinde çekişme yarattı. Bu, projeye katkıda bulunanlar tarafından uzun süredir belgelenen bir darboğazdır.

Postgres 17 bu çekişmeyi azaltır. Etki esas olarak çok çekirdekli donanım üzerinde birçok eş zamanlı aktif bağlantının olduğu yüksek eşzamanlılık örneklerinde ölçülür. Düşük eşzamanlılık yükünde Postgres 16 ile fark marjinal kalır: bu bir ölçeklenebilirlik projesidir, yalıtılmış istek başına gecikmede bir azalma değil.

Bu kazanç, bağlantı havuzlayıcısının yerini almaz, yalnızca dahili maliyetini azaltır. Aktif bağlantıların sayısı zaten darboğazınızsa, ana sürüm arka planda kalır. max_connections ayarlama kılavuzumuz ve PgBouncer işlem modu karşılaştırmamız bu konuyu daha ayrıntılı olarak ele alıyor.

Eylül 2025'in sonunda yayınlanan Postgres 18, daha yapısal bir sorunu ele alıyor. O zamana kadar okunan her Postgres diski, kendisini talep eden işlemi engelliyordu. Yeni eşzamansız giriş-çıkış (AIO) alt sistemi, bir işlemin her birini sırayla beklemek yerine birden fazla okumayı paralel olarak başlatmasına ve bunlar tamamlanırken çalışmaya devam etmesine olanak tanır.

io_method parametresi şu davranışı kontrol eder: Postgres bu destekle derlendiğinde worker (G/Ç'ye ayrılmış işlemler, varsayılan) veya Linux'ta io_uring. Sıralı taramalar, bitmap yığın taramaları ve VACUUM, özellikle yüksek gecikmeli depolamada ilk faydalananlar olacaktır: yerel NVMe yerine ağ diskleri, bulut birimleri.

Yönetilen bir Postgres teklifi sunan PlanetScale, bu I/O değişikliğine odaklanan kendi Postgres 17 ve 18 karşılaştırmalarını yayınladı. Bunlar, burada bağımsız olarak ürettiğimiz rakamlar değil, kendi altyapılarındaki ölçümlerdir. Bunu evrensel bir yüzde olarak değil, konunun gerçek yükünüz üzerinde test edilmeye değer olduğuna dair bir sinyal olarak alın.

Postgres 18'in genelleştirilmiş AIO'su, izole bir değişiklik değil, Postgres 17'de başlatılan bir projeyi sürdürüyor. Sürüm 17'de zaten akışlı G/Ç arayüzü mevcuttu ancak ANALYZE ve sıralı taramalarla sınırlıydı. Postgres 18, aynı mantığı, VACUUM ve bitmap yığın taramaları da dahil olmak üzere daha geniş bir operasyon kapsamına genişletiyor. Bu nedenle iki versiyon, G/Ç üzerine iki ayrı bahis olarak değil, bir ilerleme olarak okunur.

Diğer üç Postgres 18 değişikliği, doğrudan ham performansı ele almasalar bile izlenmeye değer.

Çok sütunlu B ağacı dizinindeki atlama taraması, sorgu baş sütununda filtreleme yapmasa bile Postgres'in bileşik dizin kullanmasına olanak tanır. Postgres 18'den önce bu senaryo genellikle tablonun tamamen taranmasını veya ek bir özel dizin oluşturulmasını gerektiriyordu.

oluşturulan sanal sütunlar (GENERATED ALWAYS AS (...) VIRTUAL), STORED belirtilmediğinde varsayılan davranış haline gelir. Sanal bir sütun, diske yazılmak yerine okunduğunda hesaplanır; bu, kaynak satır her eklendiğinde veya güncellendiğinde yazılan miktarı azaltır.

Postgres 18, SCRAM, sertifikalar veya LDAP gibi mevcut mekanizmaların yanı sıra son olarak kimlik doğrulama tarafında (RFC 8628, cihaz akışı) OAuth 2.0 desteğini ekliyor. Kimliklerini halihazırda harici bir OAuth/OIDC sağlayıcısı aracılığıyla merkezileştiren tüm kuruluşlar için önemli bir nokta.

Aurabase'de, kiracı veritabanı şu anda Postgres 16.15'de çalışıyor, 17 değil. Bu doğrudan depoda doğrulanabilir: referans CNPG görüntüsü (docker/Postgres.CNPG.Dockerfile) ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm'den başlar, özet ile sabitlenir, paylaşılan katmanla (docker/Postgres.Dockerfile) aynı ana sürümdür. 24 Ağustos 2026'da doğrulandı.

Kod aynı zamanda nedenini de belgeliyor. k8s_tenant.rs içindeki bir düzeltme yorumu, daha önceki bir geri dönüşün yanlışlıkla postgresql:17.2'ye işaret ettiğini açıklıyor. O zamanlar standart görüntünün pgvector içermemesi nedeniyle gösterilen nedenin, doğrulama sırasında yanlış olduğu ortaya çıktı. Her iki görüntünün de pgvektörü var: Filo kümesinde ölçülen 17.2'de 0.8.0, 16 standart kitap kurdunda 0.8.5.

Yorumun kendisinde belgelenen gerçek risk başka bir yerdedir: CloudNativePG, bir Küme oluşturulduktan sonra herhangi bir ana sürümün düşürülmesini yasaklar. Postgres 17'de yanlışlıkla tedarik edilen bir filonun geri dönüşü mümkün olmayacaktı; oysa Aurabase'de uçtan uca doğrulanan her şey Postgres 16'daydı.

// TENANT_POSTGRES_IMAGE tanımlanmadıysa ana sürüm korunur
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Bu, Postgres 17'ye ilişkin bir karar değildir. Bu bir operasyonel ihtiyat politikasıdır: Uçtan uca doğrulama tamamlanana kadar bir üretim filosunu ana sürüme geçirmeyin. Aynı mantık, Postgres'i CloudNativePG veya eşdeğer bir Kubernetes operatörü aracılığıyla yöneten tüm ekipler için de geçerlidir. Sorun yalnızca beklenen performans artışı değil, aynı zamanda bir şeyler ters giderse geri dönüş yoludur.

Şimdi Postgres 17 veya 18'e geçmeli misiniz?

Üç kriter evrensel bir rakam beklenmeden karar verilmesini mümkün kılmaktadır. İlk olarak, en büyük tablolarınızın boyutu ve mutasyon oranı: VACUUM zaten birkaç geçişte çalışıyorsa Postgres 17 bellek çalışma sitesi doğrudan sizin durumunuza uygulanır. Ardından depolama alanınız: Düşük gecikme süreli yerel SSD'de, Postgres 18'in eşzamansız G/Ç'si ağ birimindekinden daha azını sağlar. Son olarak, geri dönüş yolunuz: Büyük seviye düşürmeyi yasaklayan bir operatörde, önce tek kullanımlık bir ortamda test yapmak isteğe bağlı bir önlem değildir.

Somut olarak aynı kural, bir Kubernetes operatörü tarafından yönetilen tüm filolar için geçerlidir. Öncelikle hedef sürümde bir test kümesi sağlayın, ardından üretiminizin yük temsilcisini bu küme üzerinde yeniden oynatın. Yalnızca sürüm notlarını okumak yerine, bu test uçtan uca doğrulandıktan sonra gerçek kümeye dokunun. Kararınız aynı zamanda bu tür bir değişikliği karşılamak için tahsis edilmiş taban ve paylaşılan taban arasındaki seçimle de ilgiliyse, tahsis edilmiş taban ve paylaşılan taban makalemiz bu açıyı araştırıyor.

Postgres 16, 17 ve 18 arasındaki seçim yalnızca hangi sürümün "en hızlı" olduğu ile ilgili değildir. Postgres 17, büyük tablolarda gerçek bir yapısal VAKUM sorununu düzeltir ve yüksek eşzamanlılıkta çekişmeyi azaltır. Postgres 18, genelleştirilmeden önce gerçek yükünüz ve depolamanız üzerinde test yapılmasını gerektiren bir mimari değişiklik olan eşzamansız G/Ç ile daha da ileri gidiyor.

Çoğu zaman unutulan kriter performans değil, tersine çevrilebilirliktir. CloudNativePG gibi bir operatörde, büyük bir sürüm yükseltme işlemi tamamlandıktan sonra geri alınmaz. Bir üretim filosunu değiştirmeden önce asıl soru yalnızca beklenen kazanç değil, aynı zamanda testin başarısız olması halinde geri dönüş yoludur. Bu sürüm yükseltmesine hazırlanıyorsanız, üretimdeki Postgres ayarlama kontrol listemiz büyük bir sürüm değişikliğinden sonra yeniden doğrulanacak ayarların ayrıntılarını verir.