Postgres 19’daki Yenilikler: Beta Sürümün Derinlemesine Analizi

 (snowflake.com)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Büyük ölçekli üretim veritabanları için REPACK CONCURRENTLY çekirdeğe entegre edildi; SQL özellik grafiği sorguları, mantıksal replikasyon, VACUUM, performans ve daha birçok alana yayılan kapsamlı iyileştirmeler içeren bir beta sürüm
  • Bölümlerin birleştirilmesi ve bölünmesi desteği ile dizi değerlerinin senkronizasyonu sayesinde, canlı sistemlerde tasarım değişiklikleri ve veri taşımaları çok daha kolay hale geliyor
  • Autovacuum’a paralel worker ve öncelik puanı sistemi eklenerek bakım işlerinin verimi ve görünürlüğü artırılıyor
  • SQL/PGQ ile ilişkisel modeli terk etmeden mevcut veriler grafik biçiminde sorgulanabiliyor
  • Öne çıkan nokta tek bir manşet özellik değil, genişlik (breadth); uygulama, operasyon, performans ve ölçeklenebilirlik alanlarının tamamı aynı anda gelişiyor

REPACK varsayılan olarak çekirdekte

  • Tablo şişmesini geri kazanma, tabloyu yeniden yazma ve veriyi yeniden düzenleme sırasında VACUUM FULL ya da CLUSTERın getirdiği kilitlerden kaçınma ihtiyacı, uzun süredir çalışan ortamlarda tekrar tekrar ortaya çıkan bir durum
    • Bu sorunu çözen bir uzantı ekosistemi vardı ve özellikle pg_repack bu boşluğu dolduruyordu
  • Postgres 19, REPACK komutunu çekirdeğe getiriyor ve buna REPACK CONCURRENTLY desteği de dahil
    • Bunun, ortalama sürüm notu okuyucusunun beklediğinden daha fazla üretim kullanıcılarının dikkatini çekecek bir özellik olması bekleniyor

Partisyonlamanın pratikliği artıyor

  • Postgres 19, partisyonların birleştirilmesi ve bölünmesi desteğini ekliyor
  • Partisyonlama stratejileri çoğu zaman eksik bilgiyle seçilir; iş yükü, saklama süresi ve veri büyüme hızı değiştikçe bazı partisyonlar aşırı büyüyebilir ya da gereğinden küçük kalabilir
  • Bölme ve birleştirme imkanı, en baştan her şeyi yeniden kurmadan tasarımın zaman içinde evrilmesine alan açıyor
    • Q1 ve Q2 partisyonlarını tek partisyon altında birleştirme: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Q3 partisyonunu aylık bölümlere ayıran bir SPLIT PARTITION örneği veriliyor

Mantıksal replikasyonun olgunlaşması

  • Mantıksal replikasyon; migrasyon, yükseltme, raporlama sistemleri, veri taşıma, seçmeli replikasyon ve yüksek erişilebilirlik/operasyon iş akışlarında faydalı
  • En büyük iyileştirme dizi değerlerinin senkronizasyonu; böylece subscriber, publisher ile daha iyi hizalanıyor
    • Dizi durumu olmadan yapılan replikasyonda veri taşınsa da, cutover sonrasında bir sonraki üretilen ID’nin kayması sorun yaratabiliyor
    • Yayında ALL SEQUENCES desteği, dizi senkronizasyon hatası raporlama ve diziyle ilgili abonelik yenileme davranışında iyileştirmeler eklenmiş
  • Yayında tüm tabloları dahil edip bazılarını hariç tutmak için EXCEPT yan tümcesi kullanılabiliyor
  • Gerektiğinde wal_level = replica, mantıksal replikasyonu otomatik olarak etkinleştiriyor; ayrıca gerçek çalışmayı raporlayan yeni effective_wal_level ile yapılandırma hataları azalıyor ve görünürlük artıyor

Daha akıllı ve daha görünür autovacuum

  • Autovacuum artık paralel vacuum worker kullanabiliyor; bu hem global hem tablo bazında kontrol edilebiliyor
    • Global ayar örneği: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • Tabloların hangi sırayla vacuum edileceğini belirleyen yeni bir puanlama sistemi ile hangi tablonun daha acil olduğu daha iyi önceliklendirilebiliyor
    • Tablo başına ağırlık ayarlama örneği: insert tabanlı vacuum aciliyeti 3.0, genel update/delete vacuum aciliyeti 0.5
  • Yeni pg_stat_autovacuum_scores görünümü, karar sürecini görünür kılıyor
    • Vacuum ve analyze ilerleme görünümlerine ek ayrıntılar, VACUUM VERBOSE ve autovacuum loglarında bellek kullanımı ile paralellik bilgisi, ayrıca ayrı bir log_autoanalyze_min_duration eklenmesi bakım gözlemlenebilirliğini güçlendiriyor

SQL özellik grafiği sorguları geliyor

  • SQL/PGQ (SQL property graph queries) eklendi
    • Düğüm/kenar modelinin yararlı olduğu iş yükleri arasında dolandırıcılık tespiti, öneri sistemleri, ağ analizi, yetki grafikleri, tedarik zinciri ve organizasyon şemaları sayılıyor
    • Özellik grafiği tanımı örneği: CREATE PROPERTY GRAPH store_graph ile VERTEX TABLES ve EDGE TABLES belirtiliyor
  • İlişkisel modeli terk etmek yerine, zaten sahip olunan verileri sorgulamanın bir başka yolunu ekleyen bir yaklaşım
    • Bu, JSONB, tam metin arama ve uzantıların mevcut mimarinin değiştirilmesini zorunlu kılmamasıyla aynı çizgide
  • Geliştirici açısından, ayrı bir veri deposu, senkronizasyon hattı, operasyonel yüzey alanı ya da gece 2’de hata ayıklanacak yeni bir sistem eklemeden grafik tipi sorgular kullanılabiliyor

COPY daha kullanışlı hale geliyor

  • COPY FROM, birden fazla başlık satırını atlama desteği kazanıyor
    • Üst kısmında ek metadata satırları bulunan vendor, şirket içi araç veya export CSV’lerini işlerken faydalı
  • COPY FROM için ON_ERROR SET_NULL eklendi; hatalı giriş değerleri null olarak ayarlanabiliyor ve böylece "yüklemenin tamamen başarısız olması" ile "önceden temizleme zorunluluğu" arasında yeni bir seçenek sunuluyor
    • price sütununda 'N/A' ve 'MISSING' değerleri karışık olan bir dosyanın yüklenmesi örnekleniyor
  • COPY TO, tek bir JSON dizisi içeren JSON biçiminde çıktı verebiliyor; ayrıca partisyonlu tablolar da doğrudan dışa aktarılabiliyor (önceden COPY (SELECT ...) gerekiyordu)
    • Bir tabloyu geçerli bir JSON dizisi olarak dışa aktarma örneği: WITH (FORMAT JSON, ARRAY true)

SQL kullanım kolaylığı iyileştirmeleri

  • GROUP BY ALL, toplulaştırılmamış ve window olmayan hedef liste ifadelerini otomatik olarak gruplayarak keşif amaçlı SQL ve raporlama sorgularını daha temiz yazmayı sağlıyor
  • Window fonksiyonları için IGNORE NULLS ve RESPECT NULLS desteği; lead, lag, first_value, last_value, nth_value fonksiyonlarına eklendi
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING ile upsert işlemlerinde çakışan satırlar daha doğrudan döndürülebiliyor
  • UPDATE ve DELETE FOR PORTION OF ile zamansal işlemlere destek sürüyor; buna genişletilmiş RANDOM() zaman fonksiyonları da dahil

Genel performans iyileştirmeleri

  • Planner ve yürütücüde anti-join, semi-join, constant folding, append yolunda incremental sort, join öncesi toplulaştırma, join seçicilik hesaplama ve fonksiyon istatistikleri dahil çok sayıda iyileştirme var
  • Postgres, yaygın sorgu biçimlerini daha iyi tanıyıp gereksiz işleri azaltma yönünde ilerliyor
    • Bazı toplulaştırmalar join’den önce yapılarak işlenen satır sayısı azaltılıyor
    • Daha fazla NOT IN ve LEFT JOIN durumu verimli anti-join’e dönüştürülebiliyor
    • Memoize için EXPLAIN görünürlüğü artıyor, radix sort ile sıralama performansı iyileşiyor, foreign key kısıt denetimleri hızlanıyor ve COPY FROM metin/CSV girdilerinde SIMD komutları kullanılıyor
  • Birçok durumda, uygulama kodunu değiştirmeden yalnızca yükseltme yaparak daha iyi sonuç almak mümkün

Postgres 19 neden önemli

  • Tek bir özellikten çok genişlik (breadth) dikkat çekiyor
    • Uygulama geliştiricileri için: grafik sorguları, geliştirilmiş SQL sözdizimi, window fonksiyonu iyileştirmeleri, daha iyi upsert davranışı
    • Operatörler için: REPACK CONCURRENTLY, geliştirilmiş autovacuum, daha iyi izleme, çevrimiçi checksum değişikliği, artan replikasyon görünürlüğü
    • Performansa odaklanan kullanıcılar için: planner iyileştirmeleri, SIMD iyileştirmeleri, asenkron I/O görünürlüğü, daha hızlı foreign key kontrolleri, daha iyi sıralama
    • Postgres üzerinde sistem inşa edenler için: yeni hook’lar, planner advice modülü, uzantı iyileştirmeleri, FDW istatistik erişimi, uzantı ekosistemine süren yatırım
  • Yani tek bir iş yükü ya da persona değil; uygulama, operasyon, analiz ve genişletilebilirlik açısından bir veritabanı ve platform olarak aynı anda gelişiyor
  • Henüz GA değil; dolayısıyla şimdi test zamanı — uygulamaları çalıştırmak, migrasyonları denemek, uzantıları kontrol etmek, kritik sorgu planlarını doğrulamak ve mantıksal replikasyon ile bakım iş akışlarını gözden geçirmek gerekiyor

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Postgres, Oracle, MS SQL Server ve MySQL’i gerçek projelerde kullandım; SQLite’ı çok derinlemesine kullanmadım ama harika bir seçenek olduğunu biliyorum
    Bugünlerde kendi adıma Oracle ve MySQL/MariaDB’den her zaman kaçınıyorum
    Postgres harika, ama daha hafif bağlantılar ve eşzamanlı güncellenen materialized view’lar olmasını isterdim. Bağlantı havuzlayıcıları durumu iyileştirse de eşzamanlı bağlantı başına bellek kullanımı hâlâ anormal derecede yüksek ve SQL Server’daki indexed view benzeri özellikler, karmaşık veri durumlarında zarif, önemsiz ve her zaman doğru uygulamalar yapılabilmesini sağlıyor
    SQL Server pahalı olabilir ama çoğu durumda parasının karşılığını verir; veri deposunu dikkatli seçmek ileride yaşanacak birçok baş ağrısını azaltabilir

    • İlişkisel veri deposu problemleri için çoğunlukla SQLite ve MSSQL kullanıyorum
      Ücretsiz bir çözüm kullanacaksanız SQLite’ı geçmek zor ve bugün çoğu kullanım senaryosunu karşılıyor. Ama yedekleme, replikasyon ve araçlar konusunda zayıflamaya başlıyor. Sistem erişilebilirliği ve felaket kurtarmadan sorumluysanız, riski azaltmak için para harcamaktan çekinmem
      Az da olsa para ödeyecekseniz, sonuna kadar gidin. MSSQL etrafındaki geliştirici deneyimi benzersiz; SSMS ve Visual Studio’nun SQL projeleri bence bugünlerde Entity Framework türü araçlardan çok daha iyi. Buna RedGate gibi üçüncü taraf araçları da ekleyince, milyonlarca dolarlık danışmanlık paketlerinin yerini alabiliyor
      Yeni bir Oracle ya da DB2 sunucusu kuralım demem, ama zaten varsa onu ortadan kaldırmak için yeniden düzenleme yapılmasına sonuna kadar karşı çıkardım. Bu tür veritabanlarının genelde devasa korku hikâyeleri vardır ve o garip yan etkileri yeni bir motorda yeniden üretmeye çalışmak, başka seçenek kalmazsa işi tamamen bozabilir
    • Oracle, acı, ıstırap, yüksek maliyet, dava ve insani sefaletin birleşimi. Bana kalırsa, pahalı yazılım satın almanın beraberinde iyi partiler gibi yan faydalar getirmesini seven teknik olmayan orta kademe yöneticiler olmasaydı çoktan yok olmuş olurdu
    • Microsoft bile fiilen SQL Server’dan vazgeçmiş ve Azure’daki çeşitli Postgres ürünlerini geliştirmeye daha çok zaman harcıyor gibi görünüyor. 2022’den beri çıkan son büyük sürüm, birkaç yapay zeka özelliği eklemekten ibaretti
      Bir DBA olarak ağır DBA işleri yaptığınızda Postgres’in SQL Server’dan farklı bir ligde olduğunu görüyorsunuz. Postgres Linux-native ve açık kaynak olduğu için esneklik, iç gözlemlenebilirlik ve işletilebilirlik açısından SQL Server’la kıyas kabul etmiyor
      Mevcut teknoloji manzarasında SQL Server’ın fiilen öldüğünü düşünüyorum. Kullanan şirketler yalnızca eski Windows merkezli kurumlar ve onların sayısı da giderek azalıyor
    • Eşzamanlı güncellenen materialized view gerçekten olsa çok iyi olurdu. Oracle terminolojisinde sanırım buna “commit sırasında yenileme” deniyor
      Buna bir de gecikmeli yenileme seçeneği eklenebilse harika olurdu. Yani son yenilemeden sonra değişen kayıtları dikkate alıp birden fazla güncellemeyi tek seferde işleyen bir yaklaşım; Oracle’ın bunu teknik olarak nasıl yaptığını bilmiyorum. Bu özellik, neredeyse tüm açık kaynak OLTP veritabanlarına kıyasla müthiş bir ek olurdu
      OrioleDB projesini de gerçekten merak ediyorum: https://github.com/orioledb/orioledb/releases
      Birkaç yıl önce geçici tablo benzeri bir yerde sürekli rastgele ekleme ve silme yapıldığı için vacuum yüzünden epey zorlanmıştım. Bunu, değişiklikleri RAM’de daha fazla biriktirip sonra tabloya flush ederek ve böylece sayfa başına değişen satır sayısını artırarak çözdüm, ama iyi dengeyi bulmak için çok uğraştım
    • PostgreSQL daha iyi bir ürün ama MySQL/MariaDB’nin yatay ölçeklenebilirliğine sahip değil. Bu yüzden kolay kurulan bir küme gerekiyorsa ve örneğin büyük bir çevrimiçi perakende mağazası söz konusuysa, MySQL hâlâ işe yarar

  • Bilim alanında Postgres’i 15 yılı aşkın süredir kullanan biri olarak, PostgreSQL’de kolon odaklı depolama olmaması beni endişelendirmeye başlıyor
    Veri kümeleri büyüdükçe PG depolamasının sınırları daha fazla hissediliyor. cetus gibi çeşitli eklentiler bu işlevleri sağlayabilir, ama o zaman da bu eklentilerin gelecekte desteklenmeye devam edeceğine bağımlı kalıyor ve karmaşıklığı artırıyorsunuz

    • Biraz utanmazca reklam olacak ama birkaç aydır bu sorun üzerinde bir eklenti olarak çalışıyorum: https://github.com/xataio/deltax
      Başta, Postgres tablolarını depolama için kullanıp Postgres yürütücüsünü kullanmanın özündeki ek yükün fazla büyük olacağını düşündüğüm için, Timescale performansına yaklaşabilse bile bunun yine de oldukça etkileyici olacağını sanıyordum. Özel bir analitik veritabanına yaklaşabileceğini düşünmemiştim
      Ama proje ilerledikçe performans artmaya devam etti ve artık Postgres + eklenti ile analitik iş yükleri yaklaşımını kesin biçimde destekliyorum
    • Bunu bekliyorsanız veritabanını yanlış seçmiş olabilirsiniz. Kolon odaklı veritabanları ayrı bir kategoridir
      Bu, Apple’ın çamaşır makinesi satmıyor olmasından endişe etmeye benziyor
    • Bilgisayar bilimi açısından bakınca, bir işlemsel veritabanının kolon tipi yapıyı nasıl uygulayacağını pek bilmiyorum. Ölçek büyüdükçe Postgres + CDC + ClickHouse gibi, gerçek bir analitik veritabanıyla kurulan kombinasyon en güçlü seçenek gibi görünüyor
    • Veri kümeleri giderek büyüyorsa, yeni verileri PostgreSQL’de tutup eski verileri düzenli olarak veri ambarı tipi bir veritabanına arşivleyerek Postgres’i küçük tutmak daha mantıklı görünüyor
      Bugünlerde birçok şirket ana uygulamada ilişkisel veritabanının yanında anahtar-değer veritabanı ya da belge deposu da kullanıyor
    • 25 yıllık bir kullanıcı olarak mevcut durum bence gayet iyi. Daha fazlası her zaman daha iyi değildir; bunu Redis’e bakarak da görebilirsiniz

  • PostgreSQL 19'un SQL:2011 standardı tabanlı yerel application-time temporal data desteği getireceğinden neden hiç bahsedilmediğini anlamıyorum: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • Orijinal metinde bundan söz edilmemesi şaşırtıcı. Eskiden bunu tcn trigger'ları ve _archive gölge tablolarını elle ekleyerek yapıyorduk: https://www.postgresql.org/docs/current/tcn.html
      Bunun yerel olarak gelmesi, PostgreSQL'deki çoğu şey gibi gerçekten harika olur
    • Query Hints'e de sadece kısaca değinilmiş olması üzücü. Benzer başlıklı önceki yazının altında ilginç bir tartışma vardı
      https://news.ycombinator.com/item?id=48413655
    • Harika bir özellik ama dürüst olmak gerekirse doğru kullanması biraz zor bence. Ayrıca PII'nin temporal void'un bir yerlerinde uzun süre kalmamasına dikkat etmek gerekir

  • Bu yazının LLM eğitim verilerinde aşırı temsil edilen bir üslup mu kullandığını, yoksa metni cilalamak için yoğun biçimde AI mı kullanıldığını anlayamıyorum. İkinci ihtimale daha yakınım

    • “Cilalamak” ifadesi fazla cömert kalıyor. Beni daha çok rahatsız eden şey yazar bilgisinin yanıltıcı olması. craig-kerstiens Hugging Face'te bulunamıyor ve bu yazıda klavyeyle gerçekten yazılmış gibi görünen tek bir cümle bile yok
      Claude'un “X'i uzun süredir yapan biri olarak” gibi cümleler kurmasını bir tür alignment failure olarak görüyorum. LLM'ler kişisel deneyimi varmış gibi yazmamalı. Eğitim verilerinde insanlar böyle konuşmuş olabilir ama istatistiksel olarak makul bir token dizisi olsa bile, LLM'nin sahip olmadığı bir yaşam deneyimini iddia etmemesi gerektiğini düşünüyorum
    • Bu kadar cömert olmaya gerek yok. Snowflake, AI ile değiştireceğini söyleyerek teknik yazarlarını işten çıkardı: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • Bu tür düşük emekli üslup/biçim eleştirisi yorumları Hacker News tartışma yönergelerine aykırı ve yorum bölümünü temizlemek için müdahale gerekiyor. Artık komik olmaya başladı
    • Pangram bu metnin tamamen AI üretimi olduğuna hükmediyor ama Pangram'a ne kadar güvenilebileceğini bilmiyorum. Başkalarının ne düşündüğünü duymak isterim
    • AI kullanılıp kullanılmadığını tahmin etmenin moda olduğunu anlıyorum. Ama eleştirilecek bir şey varsa, nihai çıktıyı eleştirmek daha faydalı bence

  • COPY ve mantıksal replikasyon iyileştirmeleri hoşuma gitti. Şu anda PG veritabanını sidecar Databasus instance'ına yedekliyorum ama o, tüm backend + DB + Caddy'den daha ağır
    Aşağısı LLM üslubuna dair bir yakınma
    “Bu bile tek başına şunu gösteriyor: kullanıcıların gerçek bir ihtiyacı vardı ve ekosistem bu boşluğu doldurdu”, “Basit görünüyor ama gerçek operasyonel sorunları çözüyor”, “Dünyayı değiştirmiyor ama günlük veri iş akışlarını daha iyi hale getiriyor” gibi cümleleri okumaktansa, Orwell bugün yaşıyor olsaydı belki İngilizce okuma yazma bilmediğini ilan eder ve Klingon öğrenirdi

  • Grafik veritabanı özellikleri ilginç görünüyor ama GRAPH_TABLE sözdizimi fazlasıyla korkunç
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    Bu bana neo4j'yi hatırlatıyor ama 2026'da ciddi araçların doğrudan kopyalayacağı bir şey olduğunu düşünmüyorum
    Sonunda merak ettiğim şey hız. Satır düzeyi güvenlik çok faydalı bir özellik ama Postgres'in implementasyonuyla ciddi bir şey inşa etmeye çalışmak pervasızlık. Çünkü planner darmadağın oluyor ve satır başına eşleştirme yaparak performansı mahvediyor

    • Bu, Postgres'in kendi başına uydurduğu rastgele bir sözdizimi değil
      Neo4J'nin Cypher dilinden türeyen ve artık SQL standardının parçası olan SQL/PGQ
    • Satır düzeyi güvenlikte planner'ın her satırı kontrol ettiğini mi söylüyorsun? Zaten Row-level security tam olarak bu. Politikanın geçtiği satır olup olmadığını başka nasıl doğrulayacak?

  • PostgreSQL'e satır sıkıştırmanın yanı sıra blok sıkıştırma da gelse keşke. Sadece satır sıkıştırmanın etkisi fazla sınırlı
    Veriyi ZFS pool üzerinde tutup blok sıkıştırmayı açabilirsiniz ama bunun yerel desteği olursa yapılandırma yükü azalır ve performans da daha iyi olabilir

  • GROUP BY ALL düşününce gerçekten çok mantıklı geliyor ama daha önce hiç aklıma gelmemiş olması eğlenceli

  • DevOps'a daha yakın bir bakış açısından, PostgreSQL'in ardışık major sürümler arasında sonunda yerinde yükseltme desteklemesini isterdim
    Çoğu dağıtım pg_upgrade için eski ve yeni sürümü birlikte çalıştırmanın o can sıkıcı özelliğini halledebiliyor ama Docker kullanınca yeni major sürüme geçmek gerçekten işkence oluyor

  • GROUP BY ALL'ın gelmiş olması güzel. Bildiğim kadarıyla bu konsepti ilk getiren DuckDB'ydi
    DuckDB belgelerinde de çeşitli özelliklerin önce DuckDB'de sunulduğu ve GROUP BY ALL gibi özelliklerin daha sonra başka sistemlerce benimsendiği yazıyor
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql