हमारा वेयरहाउस DuckDB से हटाना
Analytics कंपनी PostHog में बार-बार होने वाले database और warehouse migrations planning, scalability testing, और engineering choices पर LLM-संचालित “easy rewrites” के प्रभाव को लेकर सवाल खड़े कर रहे हैं। Commenters DuckDB, ClickHouse, Trino, और data lake/table formats के multi-tenant, बड़े पैमाने के workloads के लिए गुण-दोष पर बहस कर रहे हैं, साथ ही DuckDB से हटने के बारे में PostHog की blog post में ठोस performance data और स्पष्ट तकनीकी औचित्य की कमी की आलोचना कर रहे हैं। कई लोगों को यह तेज़ stack churn resume-driven development और कमजोर architectural discipline का संकेत लगता है, न कि सावधानीपूर्वक मापी गई evolution का।
दायरे और आर्किटेक्चर से जुड़ी स्पष्टताएँ
- यह बदलाव ग्राहकों को दी जाने वाली एक वेयरहाउस प्रोडक्ट से संबंधित है, मुख्य analytics database से नहीं।
- ClickHouse अब भी core analytics को शक्ति देता है; DuckDB का उपयोग छोटे-से ग्राहक समूह के लिए एक अलग, pilot warehouse offering में किया जा रहा था।
- नया डिज़ाइन एक custom table format (“HogLake”) के ऊपर Trino-आधारित distributed query engine है, जिसका उद्देश्य मुख्यतः long-running modeling और ETL है, low‑latency queries नहीं।
DuckDB का अनुभव और scaling की सीमाएँ
- DuckDB कार्यात्मक रूप से काम कर रहा था, लेकिन real customer queries को संभालने के लिए बहुत बड़े pods (लगभग ~46 vCPUs और सैकड़ों GB RAM) चाहिए थे, जिनमें कुछ queries 12+ घंटे तक चलती थीं।
- Multi-tenant load के तहत (एक ही customer की कई भारी queries), यह आर्थिक रूप से अव्यवहार्य हो गया।
- प्रति-query CPU/memory उपयोग का अनुमान लगाना कठिन साबित हुआ। DuckDB client/server protocol (Quack) के बारे में बताया गया कि वह true distributed querying का समर्थन नहीं करता।
Trino + lake-style architecture के पीछे का तर्क
- Trino को अधिक flexible, distributed resource allocation देने वाला माना गया, जो bursty, heavy workloads के लिए बेहतर है।
- DuckDB को एक उत्कृष्ट single-node engine के रूप में सराहा गया, लेकिन cloud, multi-tenant संदर्भ के लिए उसे अनुपयुक्त माना गया।
- Iceberg/Delta का मूल्यांकन किया गया, लेकिन इस use case के लिए slow writes और अन्य कमियों के कारण उन्हें अस्वीकार कर दिया गया।
आलोचनाएँ: planning, churn, और methodology
- कई टिप्पणीकारों को लगता है कि कुछ महीनों में ClickHouse → DuckDB → Trino/HogLake पर स्विच करना खराब planning या “churn” है, और पहले से scale testing अपर्याप्त थी।
- कुछ लोग इसे resume-driven या “agent/LLM-driven” development के रूप में देखते हैं, जहाँ तकनीकों को गहराई से एक को tune करने के बजाय बदला जा रहा है।
- अन्य लोग experimentation का बचाव करते हैं, यह तर्क देते हुए कि scale पर वास्तविक व्यवहार अक्सर organic workloads के तहत ही सामने आता है।
अधिक तकनीकी गहराई और community engagement की इच्छा
- कई टिप्पणीकारों ने capacity prediction और testing के लिए concrete metrics, failure modes, और methodology, साथ ही custom format की आवश्यकता क्यों थी, इसकी अधिक स्पष्ट व्याख्या चाही।
- कुछ का कहना है कि scale पर forks बनाए रखना और improvements upstream करना सामान्य है, और वे patches तथा collaboration पर अधिक विवरण चाहते थे।
- चर्चा से यह स्पष्ट नहीं है कि नया Trino/HogLake setup मूल समस्याओं को निश्चित रूप से हल कर चुका है या नहीं।
विविध प्रतिक्रियाएँ
- कुछ लोग कंपनी की marketing blog शैली और website design की आलोचना करते हैं; जबकि अन्य उन्हें विशिष्ट या आकर्षक मानते हैं।
- व्यापक विषयों में deep expertise के बिना database choices की कठिनाई, leadership की pattern-matching विफलताएँ, और frequent foundational rewrites का जोखिम शामिल है।