Jepsen: ParticleDB 1.1.4
ParticleDB, जो एक Postgres-compatible database है और जिसे “formally proven” तथा AI-focused के रूप में मार्केट किया गया था, पर नए Jepsen विश्लेषण में गंभीर correctness bugs की असामान्य रूप से बड़ी संख्या पाई गई है—lost writes से लेकर `WHERE 4 = 5` जैसी nonsensical query results तक, जिनमें rows वापस आ जाती हैं। टिप्पणीकारों का तर्क है कि इन खामियों की प्रकृति और विस्तार मूलभूत design और QA विफलताओं की ओर इशारा करते हैं, संभवतः बड़े भाषा मॉडल्स पर भारी निर्भरता से और बढ़े हुए, और वे इस घटना को hype-driven database projects के लिए एक चेतावनी मानते हैं। कई लोग निष्कर्ष निकालते हैं कि ऐसी प्रणाली production use के लिए असुरक्षित है और किसी भी गंभीर data store के लिए Jepsen-style testing एक baseline होनी चाहिए।
समस्याओं का दायरा और गंभीरता
- टिप्पणीकार Jepsen रिपोर्ट को सामान्य डेटाबेस विश्लेषणों की तुलना में असामान्य रूप से कठोर बताते हैं।
- कहा जाता है कि ParticleDB में अनेक गंभीर बग हैं: क्रैश, डेडलॉक, डेटा लॉस, अजीब SQL व्यवहार (जैसे असंभव predicates का rows लौटाना, गैर-मौजूद columns पर predicates), और एक ही node पर बिना किसी fault के भी व्यापक transactional anomalies।
- कई प्रतिभागियों का तर्क है कि यह केवल स्थानीय बग नहीं, बल्कि मूलतः दोषपूर्ण डिज़ाइन (“incorrect by construction”) का संकेत है।
Marketing के दावे बनाम वास्तविकता
- मार्केटिंग की कड़ी आलोचना की गई: “formally proven” with TLA+, “PostgreSQL compatible,” production-ready builds, और अत्यधिक performance claims (जैसे Redis से तेज, Postgres से कई गुना तेज) के दावों पर।
- Jepsen रिपोर्ट नोट करती है कि कोई TLA+ spec उपलब्ध नहीं था, और बुनियादी Postgres compatibility स्पष्ट रूप से विफल रही।
- कुछ लोग बताते हैं कि test results के बाद website और wording को चुपचाप संशोधित किया गया लगता है।
Testing और QA प्रक्रिया
- कई लोग हैरान हैं कि इतने बुनियादी बग कैसे ship हो गए: उनका निष्कर्ष है कि या तो tests नहीं थे, tests प्रभावी नहीं थे, या tests चलाए ही नहीं गए।
- Jepsen का कहना है कि मौजूदा Postgres Jepsen harness supposedly पहले चलाया गया था, फिर भी tested version पर वह तुरंत fail हो जाता है।
- टिप्पणीकार इसे गहरे structural QA problems का प्रमाण मानते हैं, जिसमें automated agents पर अत्यधिक निर्भरता भी शामिल हो सकती है।
AI / “Vibecoding” की भूमिका
- बार-बार यह अनुमान लगाया गया कि database और उसके tests दोनों लिखने के लिए बड़े भाषा मॉडल्स का भारी उपयोग किया गया, जबकि मनुष्य सिस्टम को पूरी तरह समझ नहीं पाए।
- “Vibecoded database” AI-generated, खराब तरीके से validated code और documentation के लिए एक shorthand बन जाता है।
- कुछ लोग नोट करते हैं कि AI सक्षम हाथों में शक्तिशाली हो सकता है, लेकिन यहाँ इसने अनुभवहीनता और खराब निर्णय को और बढ़ा दिया प्रतीत होता है।
Vendor की प्रतिक्रिया और भविष्य का भरोसा
- एक टीम सदस्य बताता है कि तब से समस्याएँ ठीक कर दी गई हैं, engine को redesign किया गया है, daily Jepsen workloads अब चलाए जा रहे हैं, और testing मजबूत की गई है।
- अधिकांश प्रतिक्रियाएँ अत्यधिक संदेहपूर्ण हैं: सूचीबद्ध bugs को ठीक करना “table stakes” कहा जाता है, और लोग सवाल उठाते हैं कि इतनी अपरिपक्व प्रणाली को production-ready और formally verified के रूप में क्यों प्रचारित किया गया।
- कई लोग कहते हैं कि वे इस product को कभी deploy नहीं करेंगे; कुछ इसे फिर से शुरू करने या इस space को छोड़ देने का सुझाव देते हैं, reputational damage का हवाला देते हुए।
- अल्पसंख्यक का जोर इस बात पर है कि Jepsen का उद्देश्य bugs खोजना है ताकि उन्हें ठीक किया जा सके, और भविष्य के Jepsen runs से बच पाना कुछ भरोसा वापस ला सकता है।
व्यापक निष्कर्ष
- कई लोग तर्क देते हैं कि हर database vendor को Jepsen-style testing से गुजरना चाहिए, और उपयोगकर्ताओं की सुरक्षा के लिए ईमानदार, यहाँ तक कि कठोर, reports आवश्यक हैं।
- यह thread rigorous, test-driven database engineering और hype-driven, AI-accelerated development के बीच के अंतर को उजागर करता है, जो correctness की अनदेखी करता है।