pg_durable: Microsoft ने डेटाबेस के भीतर durable execution को open source किया

मूल लेख ↗ Hacker News चर्चा ↗

अवलोकन

  • pg_durable को 2026 के एक व्यापक रुझान का हिस्सा माना जा रहा है: “Postgres as queue/orchestrator,” अन्य PG-आधारित job/queue प्रणालियों के साथ।
  • चर्चा उन लोगों के बीच बँटती है जो “compute को data के पास लाने” को लेकर उत्साहित हैं, और उन लोगों के बीच जो orchestration और business logic को application code में ही रखना ज़्यादा पसंद करते हैं।

In-DB Durable Execution बनाम External Orchestrators

  • समर्थकों का तर्क है: अगर Postgres मुख्य stateful component है, तो workflows को in-DB रखना stack को सरल बनाता है, अतिरिक्त infrastructure (जैसे Temporal, Airflow) से बचाता है, latency/round-trips कम करता है, और DB snapshots को data तथा workflow state दोनों capture करने देता है।
  • आलोचकों का कहना है: cross-system workflows के लिए external orchestrators और DAG schedulers (Airflow, Temporal-जैसी प्रणालियाँ) बेहतर फिट हैं; वे control flow को परिचित भाषाओं और toolchains में रखते हैं।

उल्लेखित Use Cases और लाभ

  • लंबे समय तक चलने वाले / resumable workflows, ETL/AI pipelines, cron-जैसे jobs जिनमें exactly-once semantics और checkpoint replay हो।
  • workflows सहित “point in time” restore करने की क्षमता, जो DB state से tightly coupled ETL और AI pipelines के लिए उपयोगी है।
  • तब मदद मिलती है जब HTTP calls और processing मुख्यतः data-centric हों और पहले से database को target कर रहे हों।

चिंताएँ और आलोचनाएँ

  • “stored procedures जैसा एहसास”: hidden business logic, खराब observability, DB पर केंद्रीकृत scaling pressure, सीमित IO और external API integration का डर।
  • developer experience की समस्याएँ: awkward SQL/DSL syntax, कठिन debugging, mainstream languages और CI/CD flows की तुलना में सीमित tooling।
  • पहले से ही कठिन-से-scale databases पर लंबे समय तक चलने वाले jobs लादने की चिंता।

Tooling, Versioning, और Testing

  • कई टिप्पणियों में पूछा गया कि durable functions को version, test, debug, और release कैसे किया जाए।
  • कुछ का कहना है कि सभी DB objects (functions, triggers) वैसे भी source control और migrations में होने चाहिए; अन्य कहते हैं कि अधिकांश टीमों के पास mature DB workflows नहीं होते, इसलिए logic को code में रखना अधिक सुरक्षित है।

थ्रेड के अनुसार pg_durable कैसे व्यवहार करता है

  • Workflows को df.start(...) के माध्यम से define और start किया जाता है, जिससे एक instance ID मिलती है।
  • df.wait_for_signal प्रति-instance होता है और उस instance के भीतर “exactly once” होता है; df.start को दोबारा call करने से नए instances बनते हैं।
  • Timeouts और error handling workflow state और failed instances के रूप में सामने आते हैं, लेकिन विस्तृत error semantics पाठकों के लिए अभी भी कुछ हद तक अस्पष्ट हैं।

Meta: Postgres, Extensions, और Rust

  • इस पर side debate हुई कि क्या Postgres पर्याप्त extensible है (कई लोग rich extension ecosystem का हवाला देते हैं) या फिर अधिक modular architecture के साथ Rust rewrite की ज़रूरत है।
  • कुछ लोग in-DB orchestration को inner-platform effect मानते हैं; अन्य इसे mature, extensible system के व्यावहारिक पुन:उपयोग के रूप में देखते हैं।