pg_durable - PostgreSQL için dayanıklı SQL fonksiyonları

• PostgreSQL içinde yeniden deneme, zamanlama, paralel fan-out, koşullu dallanma işlemlerini küçük bir SQL DSL ile yöneten bir durable function eklentisi
• Konteyner veya harici hizmet olmadan yalnızca Postgres ve background worker ile çalışır
• Tüm adımlar durumu PostgreSQL'e checkpoint olarak kaydeder; bu sayede çökme, yeniden başlatma, bağlantı kopması durumlarında bile durduğu noktadan devam eder
• Kuyruk yönetimi, durum takibi, çökme kurtarma, adım koordinasyonu ve yeniden denemeleri doğrudan uygulamaya gerek kalmadan, yalnızca SQL yazarak orkestrasyon motorunun bunları yönetmesini sağlar
• Doğrudan uygulandığında 300 satırdan fazla boilerplate gerektiren işleri tek bir DSL çağrısıyla değiştirir; PostgreSQL 17 üzerinde açık kaynak olarak hemen kullanılabilir

---

Genel bakış ve temel değer

• Postgres'e gömülü, çökmeye dayanıklı (crash-proof) durable function; yeniden deneme, zamanlama, paralel fan-out ve koşullu dallanmayı küçük bir SQL DSL ile orkestre eder
• Ek altyapı olmadan yalnızca Postgres + background worker ile çalışır; ayrı konteyner veya harici hizmet gerekmez
• Kuyruk yönetimi, durum takibi, çökme kurtarma, adım koordinasyonu ve yeniden denemelerin tamamını üstlenen bir orkestrasyon motoru görevi görür; kullanıcı yalnızca SQL yazar

pg_durable olmadan uygulandığında

• 3 agregasyonu paralel çalıştırıp ardından dashboard'u yenilerken yeniden deneme ve çökme kurtarmayı da eklemek için 300 satırdan fazla boilerplate gerekir
  • Elle kurulması gerekenler: kuyruk ayarı ve yapılandırması, worker yönetimi ve polling, mesaj işleme ve durum takibi, hata işleme ve yeniden deneme, manuel adım koordinasyonu
  • Örnek kodda job_queue, job_results, job_state, workflow_steps, step_variables, scheduled_jobs gibi çok sayıda durum tablosu ile polling worker, workflow ilerletme, çökme kurtarma, paralel yürütme koordinatörü, değişken aktarımı, zamanlama ve temizlik fonksiyonları yer alır
  • Zamanlamadaki next_run hesabı için ayrıca harici bir cron parser kütüphanesi gerekir

pg_durable ile uygulandığında

• Aynı paralel agregasyon + dashboard yenileme işlemi tek bir df.start() çağrısıyla ifade edilir; & operatörüyle fan-out yapılıp ardından ~> ile join gerçekleştirilir
  • Örnek: 3 sorgu paralel dallanır, ardından refresh dashboard adımında birleşerek sonuç üretir
  • Canlı çalıştırma örneğinde 3 adım paralel yürütüldükten sonra join yapılır ve dashboard ready durumuna yalnızca 1,9 saniyede dayanıklı şekilde ulaşılır
• Kuyruk yönetimi, durum takibi, çökme kurtarma, adım koordinasyonu ve yeniden denemelerin tamamını pg_durable yönetir

Başlıca özellikler

• Varsayılan olarak dayanıklı

  • Tüm adımlar durumu PostgreSQL'e checkpoint olarak kaydeder; çökme, yeniden başlatma veya bağlantı kopması durumlarında bile workflow ayakta kalır
  • Kesildiği noktadan tam olarak olduğu gibi devam eder

• Otomatik yeniden denemeler

  • Kararsız işler için yerleşik yeniden deneme mantığı sunar; bir adım başarısız olduğunda yalnızca o adım yeniden denenir, workflow'un geri kalanı çalışmayı sürdürür
  • Manuel hata işleme kodu gerekmez

• SQL içinde tam gözlemlenebilirlik

  • Tüm workflow durumu Postgres tablolarında saklanır; çalışma geçmişi sorgulama, adım çıktılarını inceleme ve hata ayıklama standart SQL ile yapılır
  • Harici dashboard gerekmez

• Paralel yürütme

  • & operatörü veya df.join() ile bağımsız işler fan-out edilir; agregasyon, API çağrıları ve ETL adımları otomatik koordinasyonla birlikte eşzamanlı çalıştırılır

Kurulabilecek desenler

• ETL Pipelines

  • cleanup → transform → load adımlarını sıralı garantiyle bağlar; her adım önceki adımı bekler ve hata durumunda pipeline temiz biçimde durur (~> sequence, |=> variables)

• Parallel Aggregation

  • kullanıcı sayısı agregasyonu + gelir toplamı + stok kontrolünü aynı anda yürütür; birden çok sorguya fan-out yapıp hepsinin tamamlanmasını bekler (&, df.join())

• Order Processing

  • sipariş ID'sini yakalayıp doğrulama, işleme ve tamamlama adımlarına aktarır; adımlar arası değişken akışı otomatik olur (|=> capture, $var substitution, df.sleep())

• Scheduled Jobs

  • cron zamanlamasıyla API polling, kayıt arşivleme ve veri senkronizasyonu yapar; döngü kalıcı olarak çalışır ve yeniden başlatmalarda da ayakta kalır (@> loop, df.wait_for_schedule())

• Conditional Branching

  • bekleyen işleri, satır sayısını veya flag'leri kontrol ederek işleme ya da atlama dallanması yapar; dallanma mantığı uygulamada değil SQL içindedir (df.if(), ?> conditional)

• Multi-step Validation

  • veri alma → şema doğrulama → iş kuralı kontrolü → onay/red akışını kurar; her adım checkpoint alındığı için hata durumunda ilerleme kaybolmaz

• Database Maintenance

  • autovacuum'u engelleyen unsurları, tablo bloat'unu ve wraparound riskini tespit ederek inceleme için açığa çıkarır; onay beklendikten sonra yeniden başlatmalarda da dayanıklı şekilde düzeltme uygular (?> conditional, df.wait_for_signal(), @> loop)

• Azure Functions & HTTP

  • df.http() ile Azure Functions veya izin verilen HTTPS uç noktalarını doğrudan SQL içinden çağırır; belge chunking, satır zenginleştirme ve kayıt sınıflandırmayı inline işler

• Human-in-the-Loop Approval

  • rutin işleri otomatik onaylar, yüksek riskli işleri ise (büyük faturalar, yıkıcı işlemler) insan onayı sinyali gelene kadar duraklatır (df.wait_for_signal(), df.if())

Yapay zeka destekli yazım yardımı

• Workflow'u düz İngilizceyle açıklarsanız Copilot doğru durable-function SQL'ini üretir; sözdizimini öğrenmeden sadece istediğinizi tarif etmeniz yeterlidir
• Depoda yeniden kullanılabilir ajan becerisi pg-durable-sql bulunur; GitHub Copilot ve diğer ajanlara operatörler, değişken yerleştirme, döngüler ve paralel join gibi doğru SQL üretim yöntemlerini öğretir

Açık kaynak sunum

• Bekleme listesi veya lock-in olmadan tamamen açık kaynak olarak sunulur; depoyu clone edip build ederek kendi PostgreSQL'inizde hemen çalıştırabilirsiniz
• Dizüstü bilgisayarda, sunucuda veya bulutta dayanıklı orkestrasyon uygulanabilir

Azure HorizonDB yönetilen seçeneği

• Azure HorizonDB, Microsoft'un yeni PostgreSQL bulut hizmetidir; pg_durable yerleşik gelir ve yazdığınız durable function'ları korurken kurumsal ölçek, güvenlik ve yapay zeka yetenekleri ekler
  • 3 kata kadar daha hızlı performans, 128 TB'ye kadar otomatik depolama ölçeklendirme, 3.072 vCore'a kadar compute scale-out
  • Microsoft Defender ile gerçek zamanlı tehdit algılama, Microsoft Entra ID ile kimlik yönetimi
  • Filtered DiskANN vektör araması, semantik sıralama, veritabanı içi yapay zeka model kürasyonu
  • Microsoft Fabric ile neredeyse gerçek zamanlı yansıtma, VS Code entegrasyonu, GitHub Copilot bağlantısı

• Yerleşik AI pipeline'ları

  • HorizonDB, pg_durable'ın dayanıklı yürütmesinin üzerine yönetilen uçtan uca AI pipeline'ları katmanı ekler; her adım checkpoint, yeniden deneme ve çökme güvenliği sağlar
  • Adım akışı: Ingest (belge/veri yükleme) → Chunk (içeriği bölme) → Embed (vektörleştirme) → Index (DiskANN depolama) → Serve (arama/sıralama)

[GN⁺]

Hacker News yorumları

• 2026 Postgres kuyruklarının yılı olacak gibi görünüyor: DBOS[0], pgQue[1] gibi bir akım var ve topluluğun böyle seçenekler üretmesi harika
  Yine de eski bir uygulama mühendisi olarak kuyruk mantığının kodun ve Git’in içinde olmasını tercih ederim. Doğru araçlar olursa fikrim değişebilir
  [0]: https://www.dbos.dev/
  [1]: https://github.com/NikolayS/pgque

  • Çalışma biçimi daha zor olabilir ya da sadece farklı olabilir ama dokümantasyon, aranabilir yazılar, deneyim ve araçlar eksik gibi görünüyor
    Sürümleme, debug etme, test ve release nasıl yapılıyor merak ediyorum. Veri yerelliği ve stack’i sadeleştirmek için her şeyi tek yerde toplamak güzel görünüyor ama bunu “doğru” yapmaya dair çok faydalı bilgiyi kaybediyormuşuz gibi geliyor
  • “Kuyruk mantığını kodda tutmak isterim” görüşüne katılıyorum. Verinin kendisinden çok, o veri üzerinde yapılacak işlemler çok daha sık değişiyor; işlemi her değiştirdiğinizde migration yapmak zorunda olmak bana mantıklı gelmiyor
    Supabase’de biraz karmaşık bir şey yapmak istediğinizde Postgres fonksiyonları yazmak zorunda kalmanızdan da bu yüzden gerçekten nefret etmiştim. Yine de önceki startup’ta Postgres üzerinde basit bir iş kuyruğunu kendimiz kurmuştuk ve pgQue gibi bir şey olsaydı muhtemelen çok daha rafine olurdu
  • Postgres 7 zamanından beri hayranıyım ve deneysel olarak mümkün olduğunca çok şeyi PostgreSQL içine koymaya çalıştım, ama en azından geliştirici deneyimi ve gözlemlenebilirlik hâlâ yetersiz
    Multi-master eklentileri de hemen kullanılabilir ve tamamen güvenli şeyler değil, bu yüzden veritabanını ölçeklendirme ihtiyacını öne çekecek, yazma ağırlıklı karmaşık işleri içine koyma konusunda temkinliyim
  • DB trigger’larının olduğu projelerde SQL kodunu da Git’e koyarak yönetiyorduk
    Hatta yerel kurulumda trigger’ların yerel veritabanına girmesi için bunu Django migration’larının içine ittiğimiz de oldu

• Bunun stored procedure kokusu var. Unit test de zor, sürüm kontrolü de zor; iş mantığı veritabanının içinde saklanıp bir “gizli beyin”e dönüşüyor
  Gürültülü workload’ları izole etmek de zor, gözlemlenebilirlik de yok ve ölçekleme baskısı tamamen Postgres’in üstüne biniyor. Özellikle API çağrıları gibi I/O eksikliği dikkat çekiyor. Yerel veritabanı içinde çalışan işler için fena değil ama kullanım alanı dar görünüyor

  • Stored procedure’ler de doğru kullanılırsa harikadır. Sürüm kontrolü için monoton artan bir ID’yi ismin sonuna eklersiniz; breaking change gerektiğinde ID’yi artırır, eski sürümü de artık kullanılmayana kadar bırakırsınız
    Tabii veritabanı upgrade sürecinizin düzgün olması gerekir. Ekipten biri root yetkisiyle kafasına göre SQL migration çalıştırıyorsa zor zamanlar yaşarsınız
    Unit test de diğer SQL testleriyle tamamen aynı şekilde yapılabilir; sadece veritabanını ayağa kaldırmanız gerekir. Stored procedure’leri test edemiyorsanız bu, SQL’in kendisini test etmenin de bir yolu olmadığı anlamına gelir ve asıl sorun budur
    Stored procedure’lerin alternatifi iş mantığını veritabanına hiç koymamak değil; çoğu zaman SQL’in kod tabanının her yanına dağılması, test etmenin zorlaşması, sürüm kontrolü ve kapsülleme açısından kötü bir tablo ortaya çıkması ve gereksiz yavaşlık demektir
    Gözlemlenebilirlik kısmı kısmen doğru; SQL sorunlarını incelemek çoğu programlama diline göre daha zahmetli. Ama stored procedure’ler I/O ve ölçekleme sorunları yaratıyorsa yanlış kullanılıyorlardır; doğru kullanıldıklarında ise çoğu zaman I/O’yu ciddi biçimde azaltıp ölçeklenebilirliği iyileştirirler

• Doğru anladıysam, Pi LLM harness geliştiricilerinin yaptığı Absurd mümkün olduğunca saf veritabanı erişimini azaltmaya çalışıyor gibi görünüyor. Ben de bu konuya daha yeni bakmaya başladım
  https://github.com/earendil-works/absurd

  • Küçük bir düzeltme ama absurd, Mario Zechner earendil’e katılmadan önce başlamış earendil’in özgün projesi gibi görünüyor ve commit’lerde de onu göremedim
    Elbette tüm ayrıntıları bilmiyorum, o yüzden gerçekten merak ediyorum

• “Kullanılmaması gereken durumlar” kısmında “workflow’nun büyük kısmı Postgres’in dışında ve birden fazla heterojen sisteme yayılıyorsa” deniyor; öyleyse bu projenin Temporal gibi bir şeyle nasıl kıyaslanabildiğini anlayamıyorum
  Bu tavsiyenin ima ettiği sınırlamayı yanlış anlayıp anlamadığımı merak ediyorum

  • Katılıyorum. Örnek olarak verilen https://github.com/microsoft/pg_durable/blob/main/examples/i... bağlantısına bakınca projenin değer önerisi çok anlaşılmıyor
    Teknik olarak ilginç bir başarı olabilir ama böyle bir SQL okumak oldukça tuhaf
    SELECT df.start(
@> (
($$SELECT ... FROM demo.invoices WHERE status = 'pending'$$ |=> 'inv')
~> df.if_rows('inv',
$$UPDATE ... SET status = 'processing'$$
~> (df.http(...) |=> 'resp')
~> df.if($$SELECT $r.ok$$,
-- classify, branch, wait for signal ...
),
df.sleep(5)
)
),
'invoice-approval-pipeline'
);

• Şirkette Azure’a bağlı durumdayız ve Azure PostgreSQL’in modern özelliklere yetişmesini hâlâ bekliyoruz
  Örneğin şunu kullanamıyoruz: https://www.paradedb.com/blog/hybrid-search-in-postgresql-th...
  Ultra geniş yüksek boyutlu vektörler de desteklenmiyor. pg_durable’ı açık kaynak yapmak güzel ama keşke önce AWS’de doğal olarak alınabilen temel özellikler eklense

  • ParadeDB AGPL lisanslı olduğu için büyük bulut sağlayıcılarında genel olarak sunulması zor. Yine de Azure HorizonDB’de https://github.com/timescale/pg_textsearch kullanılabiliyor ve yakında Flex’e de gelme ihtimali yüksek
    Açık konuşayım, pg_textsearch’ün bakımını yapan kişiyim ve şu anda Azure’dayım. Vektör desteğiyle ilgili ne demek istediğini tam anlayamadım; Azure’un sunduğu pgvector + diskann’ın ötesinde bir şey mi isteniyor, merak ettim
  • Vektör arama için Azure Cosmos DB daha uygun değil mi diye düşünüyorum
  • Muhtemelen zaten değerlendirmişsinizdir ama neden doğrudan yalın bir VM oluşturup en güncel Postgres sürümünü kurmadığınızı merak ediyorum
  • Azure PG ekibinde Postgres’in AI özelliklerinden sorumlu PM’im. İstenen özellikler aslında sunuluyor ve son 3–6 ayda ciddi ilerleme kaydedildi
    Hibrit arama (BM25 + vektör) tarafında ParadeDB’nin pg_search’ü de AWS’nin yerel bir özelliği değil; EC2 üzerinde sizin barındırmanız gerekiyor. Azure PostgreSQL için aynı BM25 sıralama modelini sağlayan pg_textsearch’ü yerel hâle getirdik ve ana katkıcısı şu anda Azure Postgres ekibinde
    Belgeler: https://learn.microsoft.com/en-us/azure/horizondb/ai/full-te...
    Yüksek boyutlu vektörlerde ise aslında daha öndeyiz. HNSW kullanan pgvector’un sınırı 2.000 boyutken Azure, vektör depolama ve arama için pgvector’u destekliyor; yüksek boyutlu ve büyük ölçekli iş yükleri için de Microsoft’un grafik tabanlı vektör indeksi pg_diskann’ı sunuyor. Bu, 16.000 boyuta kadar destek veriyor ve grafik dolaşımı sırasında WHERE koşullarını değerlendiren gelişmiş indeks içi filtreleme sağlıyor; böylece seçici koşullarda geri çağırma oranı düşmüyor
    pgvector: https://learn.microsoft.com/en-us/azure/horizondb/ai/vector-...
    DiskANN yüksek boyut desteği: https://learn.microsoft.com/en-us/azure/horizondb/ai/vector-...
    Bu özellikler şu anda Azure PostgreSQL’de, özellikle de Azure HorizonDB Preview’da kullanılabiliyor. Belirli bir iş yükü varsa daha somut şekilde inceleyebiliriz

• Bu bana, Apache Airflow gibi DAG zamanlayıcılarının çok uzun zaman önce çözdüğü eski bir probleme getirilen yanlış bir çözüm gibi geliyor
  Kontrol akışını neden kod yerine veritabanında saklamak isteyesiniz ki, garip geliyor. Projeyi küçümsemek için söylemiyorum, sadece henüz tam anlayabilmiş değilim

  • Microsoft’un bu tür kullanım için Durable Task adlı bir framework’ü[1] var; Temporal gibi kendi barındırdığınız bağımsız bir servis olarak da çalışabiliyor, Azure Functions üzerinde sunucusuz olarak da çalıştırılabiliyor. Yanlış hatırlamıyorsam Airflow ve Temporal’dan da önce çıkmıştı
    Bu proje ise daha çok veritabanına özgü kullanım senaryolarına yönelik görünüyor. Avantajı, iş akışını satır satır takip etmek için loglarla kod tabanını karşılaştırmak zorunda kalmadan, işlerin tam durumunu doğrudan veritabanının içinde izleyebilmeniz olabilir. Yük ve gecikme de daha düşük olabilir, ayrıca operasyonel olarak ayakta tutulması gereken bileşen sayısını bir azaltma etkisi de olabilir
    [1] https://learn.microsoft.com/en-us/azure/durable-task/common/...
  • Airflow gibi dış araçlar veritabanı yükünü bilemez. Geliştirici eşzamanlı 200 worker’ı veritabanına bindirirse diğer iş yükleri etkilenebilir
    Buna karşılık bu yaklaşım şu anda tam böyle çalışıyor gibi görünmese de, gidiş-dönüş gecikmesi maliyeti olmadan neredeyse gerçek zamanlı performans geri bildirimi alıp kendini ayarlama potansiyeline sahip olabilir

• Belgeleri ve örnekleri okusam da bazı noktalar hâlâ net değil. df.wait_for_schedule() nasıl çalışıyor, merak ediyorum
  Uygulamadan çağrıldığında idempotent mi; aynı parametrelerle iki kez çalıştırılırsa tik iki kez mi tetikleniyor, yoksa bu sorgu konsolundan bir kez elle çağrılan bir şey mi, ya da migration script'inin bir parçası olarak mı çalıştırılıyor, anlayamadım
  Örnek[0]'deki timed_out değerinin zaman aşımında dönen sabit bir sabit olup olmadığını da merak ediyorum. Hata veya exception işleme tarafı da hemen görünmüyor
  [0] https://github.com/microsoft/pg_durable/blob/main/examples/i...

  • df.start() çağrıldığında bir durable function oluşturulur ve aynı anda çalıştırılmaya başlanır. Bu çağrı, o çalıştırmayı temsil eden bir instance ID döndürür; daha sonra bu çalıştırmaya referans vermek için kullanılabilir
    Bu durable function içinde df.wait_for_signal() çağrılır; bu çağrı ilgili function instance içinde tam olarak bir kez çalıştığı için yinelenmesi mümkün değildir. df.start() çağrısının kendisi zaman aşımına uğrayıp yeniden çalıştırılırsa yineleme olabilir, ancak bu durumda farklı bir function instance oluşturulur
    SQL yürütümü sırasında işlenmemiş bir hata oluşursa function instance başarısız olur ve durum alanında oluşan hatanın kendisi aynen görünür

• Veritabanı dışındaki bir orkestrasyon aracı yerine bunun neden kullanılması gerektiğini açıklayabilir misiniz? README'yi ve örnekleri okusam da hâlâ tam kavrayamadım

  • Veritabanının snapshot PITR özelliği kullanılırsa belirli bir andaki durable işler de hepsi birlikte geri yüklenir
    Aynı veri deposuna ait diğer bileşenlerle yedekleri senkronize etme ihtiyacı olmadığı için ETL pipeline'ları veya durum makinesi tarzı işler için uygundur. ETL çoğunlukla SQL ise gerçek işin aynı sunucuda çalışması da avantaj sağlar
  • Katkı sağlayan biri olarak bakınca, Microsoft'un Postgres müşterileri oldukça dengeli biçimde iki gruba ayrılıyor. Mümkün olduğunca çok şeyi veritabanı içinde yapmak isteyenler ve uygulama ile hesaplamayı veritabanı dışında tutmak isteyenler
  • Mimari içinde veritabanı tek stateful bileşen ise bu bazen kullanışlıdır
    Tüm durum tek bir veritabanında olduğunda tutarlı yedek alma olasılığı da daha yüksektir
  • Uygulama workflow'larıyla iyi entegre olabilir. Örneğin frontend uygulamasındaki kalıcı bağlantılarda ilerleme durumunu göstermek mümkün olabilir; uygulama yeniden başlasa bile devam eden workflow'lar kurulabilir ve bir altyapı bileşeni daha eklemek gerekmez
    https://transport.data.gouv.fr bu amaçla Postgres kullanıyor ve oldukça fazla işlem yapan bir Elixir uygulamasında bunun faydasını görüyor. pg_durable'ı henüz iyi bilmiyorum ama benzer çözümler kullanmış ya da uygulamış olduğum için buna katılıyorum

• Veritabanı zaten ölçeklendirilmesi en zor altyapı bileşenlerinden biri değil mi? Neden bunun üstüne bir de uzun süre çalışan işler bindirmek isteyelim, pek anlayamıyorum

  • Postgres üzerinde uzun süre çalışan işler yürütmek hiç de yeni bir şey değil. Örneğin pg_cron var
    Sonuçta bu tür workload'lar, dış bir bileşen tarafından tetiklensin ya da tetiklenmesin, veritabanına karşı çalışacak işlerdir. Veri veya yapay zeka pipeline'larında ek bileşenlerin getirdiği gidiş-dönüşleri ve hata noktalarını önlemek için veritabanından HTTP sorguları göndermek de daha yaygın hâle geldi. Yine de hesaplamayı veriye mi götürmek, veriyi hesaplamaya mı götürmek gerektiği tartışmalı ve büyük bir tasarım tercihidir

• Popüler bir programlama dili veya sanal makine zaten determinism, ölçülebilir ve denetlenebilir adım adım yürütme, çalışma zamanı durumunu duraklatma, serialize/deserialize edip yeniden sürdürmeyi destekleseydi, buna gerek kalmayacak bir başka https://en.wikipedia.org/wiki/Inner-platform_effect örneği gibi geliyor bana