विश्लेषणात्मक कार्यों के लिए Postgres को 300x तेज़ बनाना: बैचिंग, ऑपरेटर फ्यूज़न, और SIMD
PostgreSQL के एक नए Rust-आधारित पुनर्लेखन, pgrust, का दावा है कि batch execution, operator fusion, SIMD, और एक पुन:डिज़ाइन किए गए scheduler की मदद से यह analytic queries को 300x तक तेज़ कर सकता है, और शुरुआती benchmarks संकेत देते हैं कि यह कुछ workloads पर ClickHouse जैसे systems की बराबरी या उनसे बेहतर प्रदर्शन कर सकता है। Commenters इसके AI-generated code के भारी उपयोग, इतनी तेज़ी से बने systems-level database की reliability और safety, और क्या formal verification तथा fuzzing production में उस पर भरोसा करने के लिए पर्याप्त हैं, इस पर तीव्र रूप से विभाजित हैं। Licensing भी एक बड़ा विवाद है: कुछ के अनुसार AGPL का चुनाव cloud giants को इस काम से कमाई करने से रोकने के लिए ज़रूरी है, जबकि अन्य मानते हैं कि यह corporate adoption और contributions को रोक देगा, जिससे forks या alternative licenses की चर्चा तेज़ हो गई है।
लाइसेंसिंग, बिज़नेस मॉडल, और अपनाना
- मुख्य चर्चा AGPL लाइसेंस पर केंद्रित है। कई लोग कहते हैं कि यह एक “डीलब्रेकर” है, खासकर कॉर्पोरेट सेटिंग्स में जहाँ AGPL पर प्रतिबंध होता है या उसे बहुत हतोत्साहित किया जाता है, और यह कोर Postgres में upstream करने को भी रोकता है।
- समर्थकों का तर्क है कि AGPL (या इसी तरह का copyleft) अब डेटाबेस के लिए मानक है, ताकि क्लाउड प्रदाता permissively licensed काम से कमाई करें लेकिन वापस योगदान न दें, इसे रोका जा सके।
- कई लोग dual-licensing (AGPL + commercial) और उचित contribution agreements बनाने का सुझाव देते हैं; कुछ को चिंता है कि इससे केवल core company को ही समुदाय के काम से वित्तीय लाभ मिलेगा।
- AGPL वास्तव में क्या माँगता है, इस पर भ्रम और असहमति है; कुछ का कहना है कि सामान्य DB clients सुरक्षित हैं, जबकि अन्य जोर देते हैं कि AGPL कानूनी रूप से अभी तक परखा नहीं गया है और जोखिम भरा है।
- कुछ का कहना है कि अगर प्रदर्शन का लाभ वास्तविक है, तो बड़े खिलाड़ी AI की मदद से अपेक्षाकृत कम लागत पर Postgres को permissive terms के तहत स्वयं re-port कर सकते हैं।
AI-जनित पोर्ट और कॉपीराइट चिंताएँ
- repo के commit history में एक महीने में हज़ारों AI-coauthored commits दिखते हैं; कुछ लोग इसे “AI slop” या “vibecoded” कहते हैं और human review की गहराई पर सवाल उठाते हैं।
- प्रक्रिया का वर्णन यह है: C→Rust via c2rust, फिर भारी LLM refactoring और tests। आलोचकों का तर्क है कि यह स्पष्ट रूप से एक derived work है और इसे AGPL के तहत relicence करना नैतिक रूप से (यदि कानूनी रूप से नहीं) संदिग्ध है।
- इस पर बहस है कि क्या LLM-generated code पर copyright लागू होता भी है या नहीं; कुछ लोग कहते हैं कि ऐसे में license शायद अप्रासंगिक हो सकता है, लेकिन इसे अस्पष्ट बताया गया है।
प्रदर्शन दावे और बेंचमार्क
- marketing claim है कि यह analytics के लिए Postgres से लगभग 300x तेज़ है; कई commenters को इस पर संदेह है।
- आलोचकों का कहना है कि demo में Postgres parallelism बंद कर दी गई थी, जिससे तुलना खराब दिखी; maintainers का कहना है कि 300x का आँकड़ा ClickBench परिणामों से आता है जहाँ parallelism सक्षम थी।
- एक बाहरी expert ने reportedly ClickBench runs की समीक्षा की और बड़े speedups की पुष्टि की; अन्य लोग सावधान करते हैं कि tests विशिष्ट memory-resident analytic workloads को दर्शा सकते हैं, सामान्य OLTP उपयोग को नहीं।
- चर्चा में यह भी नोट किया गया है कि कई workloads memory- और cache-bound होते हैं; columnar और vectorized execution कुछ analytic queries के लिए सचमुच बहुत बड़े gains दे सकते हैं।
सहीपन, विश्वसनीयता, और दीर्घायु
- project team सहीपन पर ज़ोर देती है: लगभग 1000 functions का formal verification, Postgres के खिलाफ differential fuzzing, और fault testing तथा verification के लिए external engagements।
- वे pgrust में लगभग 100 bugs और Postgres में लगभग 20 bugs पाए जाने की रिपोर्ट करते हैं, जिनमें सूक्ष्म floating-point bugs भी शामिल हैं।
- फिर भी कई लोगों को चिंता है कि AI-जनित, नया system DB Postgres की दशकों की battle-testing के बराबर नहीं हो सकता; data corruption और long-term maintenance को लेकर चिंताएँ बार-बार उठती हैं।
आर्किटेक्चर, सुविधाएँ, और उपयोग के मामले
- pgrust table access method के रूप में columnar storage, adaptive planning, resource throttling और work stealing के साथ नया query scheduler, और DB cloning को तेज़ करने के लिए एक “test mode” जोड़ता है।
- इसे embed किया जा सकता है (Wasm सहित), और यह per-test ephemeral DBs, WAL के माध्यम से read-only analytics replicas, और हल्के deployments का समर्थन कर सकता है।
- कुछ लोग इसे एक promising Postgres-compatible analytic engine मानते हैं; अन्य लोग संदेह करते हैं कि यह Postgres को विस्थापित करेगा, लेकिन विशिष्ट workloads के लिए साथ-साथ चल सकता है।