डेटा लेक के बिना BI

ज़्यादातर स्टार्टअप BI प्रोजेक्ट बहुत जल्दी और बहुत बड़े पैमाने पर शुरू होते हैं।

एक संस्थापक एक साधारण सवाल पूछता है: "क्या इस चैनल से आए उपयोगकर्ता अपने पहले रन के बाद लौट रहे हैं?" इसका जवाब एक क्वेरी होना चाहिए। इसके बजाय, यह अक्सर एक प्लेटफ़ॉर्म प्रोजेक्ट बन जाता है: हर स्रोत को जोड़ो, एक वेयरहाउस बनाओ, इवेंट परिभाषित करो, पहचान साफ़ करो, डैशबोर्ड जोड़ो, और इंतज़ार करो।

वह काम आख़िरकार मायने रखता है। लेकिन एक छोटी टीम के लिए, यह पहला गलत कदम हो सकता है। प्रोडक्ट डेटाबेस पहले से ही वह ज़्यादातर जानता है जो संस्थापक को जानने की ज़रूरत है। यह जानता है कि किसने साइन अप किया, किसने कुछ चलाया, उन्होंने क्या उपयोग किया, इसकी लागत कितनी थी, क्या विफल हुआ, और क्या वे लौटे।

असली समस्या यह नहीं है कि सच्चाई कहाँ रहती है। यह है कि किसी एजेंट को उस सच्चाई का विश्लेषण कैसे करने दिया जाए, बिना कच्चे प्रोडक्शन डेटाबेस को उजागर किए।

यही वह पैटर्न है जिसका उपयोग हम VM0 में करते हैं: एक मास्क्ड, रीड-ओनली Neon ब्रांच जो हमारे एजेंट को BI चलाने के लिए पर्याप्त सच्चाई देती है, बिना उन्हें वह डेटा दिए जो उन्हें कभी नहीं देखना चाहिए।

संस्थापक की समस्या: सवाल डेटा टीम से पहले आ जाते हैं

शुरुआती-चरण की कंपनियों में सवालों की कमी नहीं होती। उनके पास समय की कमी होती है।

हर दिन, संस्थापक टीम ऐसी चीज़ें जानना चाहती है जैसे:

• क्या कल का ट्रैफ़िक असली उपयोगकर्ताओं में बदला?
• कौन से साइनअप चैनल ऐसे लोग पैदा करते हैं जो वास्तव में कुछ चलाते हैं?
• क्या पहली बार के उपयोगकर्ता 7 या 30 दिनों के बाद लौटते हैं?
• कौन से भुगतान वाले खाते शांत होते जा रहे हैं?
• कौन सा मॉडल रूट लागत बढ़ा रहा है?
• क्या ट्रायल का दुरुपयोग करने वाले लोग कन्वर्ट होने से पहले कंप्यूट जला रहे हैं?
• क्या कल से प्रोडक्ट हेल्थ बेहतर हुआ या बदतर?

इनमें से कोई भी सवाल असामान्य नहीं है। ये एक स्टार्टअप के संचालन की लय हैं।

लेकिन पारंपरिक BI रणनीति से इनका जवाब देने में बहुत ज़्यादा ओवरहेड पैदा होता है। आप आमतौर पर प्रोडक्ट डेटाबेस से डेटा को दूसरे सिस्टम में ले जाकर शुरुआत करते हैं। फिर आप उसे नॉर्मलाइज़ करते हैं, मेट्रिक्स परिभाषित करते हैं, संबंधों को फिर से बनाते हैं, और डैशबोर्ड सेट करते हैं। टीम को एक साफ़ एनालिटिक्स स्टैक मिलता है, लेकिन संस्थापक अक्सर एक ऐसे जवाब के लिए दिनों या हफ़्तों तक इंतज़ार करता है जो एक SQL क्वेरी के रूप में शुरू हो सकता था।

एक छोटे स्टार्टअप के लिए, यह समझौता उल्टा हो सकता है। अपने पहले 20 संचालन-संबंधी सवाल पूछने के लिए आपको एक पूर्ण डेटा प्लेटफ़ॉर्म की ज़रूरत नहीं है। आपको उस सच्चाई के स्रोत को क्वेरी करने का एक सुरक्षित तरीका चाहिए जो आपके पास पहले से है।

डेटाबेस पहले से ही सच्चाई का स्रोत है

VM0 में, प्रोडक्ट डेटाबेस में वे तथ्य होते हैं जो कई संस्थापक-स्तरीय निर्णयों के लिए मायने रखते हैं:

• संगठन और उपयोगकर्ता
• साइनअप और सब्सक्रिप्शन स्थिति
• एजेंट रन और शेड्यूल
• क्रेडिट खपत और उपयोग इवेंट
• चुने गए मॉडल और प्रोवाइडर रूट
• कनेक्टर स्थिति
• विफलता स्थिति और टाइमस्टैम्प

वे संबंध पहले से ही मौजूद हैं। वे किसी भी डाउनस्ट्रीम डैशबोर्ड से ज़्यादा ताज़ा हैं, और वे दर्शाते हैं कि प्रोडक्ट वास्तव में कैसे काम करता है।

यह मायने रखता है क्योंकि कई शुरुआती BI सवाल रिलेशनल होते हैं। एक संस्थापक केवल पेज व्यू या रन गिनती नहीं चाहता। वे सिस्टम भर में व्यवहार को जोड़ना चाहते हैं:

इस चैनल से रजिस्टर हुए उपयोगकर्ताओं में से, कितनों ने दिन शून्य पर कुछ चलाया, और कितने अपने पहले रन के बाद लौटे?

या:

कौन से भुगतान वाले संगठनों ने पिछले 7 दिनों में कुछ नहीं चलाया, और क्या वे पहले सक्रिय दिखते थे?

या:

नए ट्रायल खातों ने अपने पहले 6 घंटों में, हमारे दुरुपयोग गश्त बदलने से पहले और बाद में, कितना कंप्यूट जलाया?

वे सवाल स्वाभाविक रूप से प्रोडक्ट डेटाबेस में बैठते हैं। वे तब बहुत कठिन हो जाते हैं जब हर जवाब किसी अलग प्लेटफ़ॉर्म में डेटा ले जाने से शुरू होता है।

असुरक्षित शॉर्टकट है कच्ची प्रोडक्शन एक्सेस

लुभावना शॉर्टकट स्पष्ट है: बस एजेंट को प्रोडक्शन क्वेरी करने दें।

यह स्वीकार्य नहीं है।

एक प्रोडक्शन डेटाबेस में कंपनी की सबसे संवेदनशील सामग्री हो सकती है: ईमेल पते, प्रॉम्प्ट, चैट सामग्री, क्रेडेंशियल, एन्क्रिप्टेड प्रोवाइडर स्थिति, लॉग, त्रुटि संदेश, API की, और आंतरिक संचालन रिकॉर्ड। भले ही एजेंट सावधान हो, कच्ची एक्सेस एक सीमा संबंधी समस्या पैदा करती है। एजेंट बहुत ज़्यादा देख सकता है। किसी क्वेरी, रिपोर्ट या स्क्रीनशॉट में एक गलती ऐसी जानकारी लीक कर सकती है जिसे टीम कभी उजागर करने का इरादा नहीं रखती थी।

राइट एक्सेस तो और भी बदतर है। BI को प्रोडक्शन को बदलने में सक्षम नहीं होना चाहिए। एक विश्लेषक, चाहे मानव हो या एजेंट, उपयोगकर्ता डेटा बदलने से एक गलत कमांड भर की दूरी पर नहीं होना चाहिए।

तो सवाल यह नहीं है कि क्या एजेंट SQL लिख सकते हैं। वे लिख सकते हैं। सवाल यह है कि क्या आप उन्हें उपयोगी होने के लिए पर्याप्त सच्चाई दे सकते हैं, जबकि गोपनीयता और सुरक्षा को कठोर बाधाओं के रूप में बनाए रखें।

हमारे लिए, वे बाधाएँ ही मुख्य बात हैं:

• एजेंट को कच्चे प्रॉम्प्ट नहीं देखने चाहिए।
• एजेंट को कच्चे ईमेल नहीं देखने चाहिए।
• एजेंट को क्रेडेंशियल या सीक्रेट नहीं देखने चाहिए।
• एजेंट को संवेदनशील फ्री-टेक्स्ट लॉग नहीं देखने चाहिए।
• एजेंट के पास BI स्रोत पर राइट एक्सेस नहीं होनी चाहिए।
• संस्थापक टीम को फिर भी व्यावहारिक संचालन सवाल जल्दी पूछने में सक्षम होना चाहिए।

यही उस सिस्टम का आकार है जिसकी हमें ज़रूरत थी।

सुरक्षित बीच का रास्ता: एक मास्क्ड, रीड-ओनली डेटाबेस

Neon एक उपयोगी पैटर्न को संभव बनाता है क्योंकि ब्रांच एक Postgres डेटाबेस की सस्ती, पृथक प्रतियाँ होती हैं। आप एक प्रोडक्शन-जैसी ब्रांच बना सकते हैं, उसे ट्रांसफ़ॉर्म कर सकते हैं, और प्रोडक्शन के बजाय उस ब्रांच को उजागर कर सकते हैं।

VM0 में, हम इसका उपयोग वह बनाने के लिए करते हैं जिसे हम MaskDB कहते हैं।

प्रवाह सरल है:

1. प्रोडक्शन Neon पैरेंट ब्रांच से शुरू करें।
2. एक शेड्यूल पर एक नई ब्रांच बनाएँ।
3. PostgreSQL Anonymizer और VM0-विशिष्ट मास्किंग हेल्पर इंस्टॉल करें।
4. संवेदनशील कॉलम के लिए सुरक्षा लेबल लागू करें।
5. ब्रांच पर स्टैटिक एनोनिमाइज़ेशन चलाएँ।
6. उन फ़ील्ड के लिए अंतिम कस्टम मास्क लागू करें जिन्हें विशेष हैंडलिंग की ज़रूरत है।
7. SELECT एक्सेस के साथ एक masked_readonly भूमिका बनाएँ।
8. एजेंट को उस भूमिका को क्वेरी करने दें, प्रोडक्शन को नहीं।

महत्वपूर्ण विवरण यह है कि मास्किंग स्टैटिक है। एजेंट के कनेक्ट होने से पहले संवेदनशील मानों को मास्क्ड ब्रांच पर फिर से लिखा जाता है। यह हर डाउनस्ट्रीम क्वेरी से यह याद रखने को कहने से अलग है कि क्या नहीं चुनना है। ब्रांच स्वयं सीमा है।

हमारे MaskDB में, क्रेडेंशियल और सीक्रेट को संशोधित कर दिया जाता है। ईमेल और फ़ोन नंबर आंशिक रूप से मास्क किए जाते हैं। उपयोगकर्ता सामग्री जैसे प्रॉम्प्ट, चैट संदेश, शेड्यूल प्रॉम्प्ट और एजेंट आउटपुट हटा दिए जाते हैं। त्रुटि टेक्स्ट को पूरे स्टैक या संदेश के बजाय एक श्रेणी तक कम कर दिया जाता है। जिन तालिकाओं को विश्लेषण में कभी नहीं दिखना चाहिए उन्हें पूरी तरह हटाया जा सकता है।

साथ ही, org_id, user_id, और clerk_user_id जैसे अपारदर्शी पहचानकर्ता जॉइन-योग्य बने रहते हैं। यही BI को संभव बनाता है। हमें एजेंट को किसी व्यक्ति का ईमेल पता या प्रॉम्प्ट टेक्स्ट जानने की ज़रूरत नहीं है। हमें इसे यह जानने की ज़रूरत है कि वही संगठन रजिस्टर हुआ, एक कार्य चलाया, क्रेडिट खपत किया, सब्सक्राइब किया, निष्क्रिय हुआ, या बाद में लौटा।

वह संतुलन ही पूरी बात है: मानव-पठनीय और संवेदनशील सामग्री को मास्क करें, रिलेशनल रीढ़ को संरक्षित रखें।

सीमा मौजूद होने पर एजेंट क्या कर सकते हैं

एक बार मास्क्ड रीड-ओनली डेटाबेस मौजूद हो जाने पर, एजेंट बहुत जल्दी उपयोगी बन सकता है।

यह सीधे प्रोडक्ट डेटा के विरुद्ध सवाल पूछ सकता है:

• 7-दिन और 30-दिन उपयोगकर्ता रिटेंशन
• रजिस्ट्रेशन-से-पहले-रन एक्टिवेशन
• पहले-रन-आधारित रिटेंशन
• भुगतान वाले संगठनों की निष्क्रियता
• सब्सक्रिप्शन स्थिति और चर्न निगरानी
• चुने गए मॉडल के अनुसार मॉडल उपयोग
• बिल्ट-इन बनाम उपयोगकर्ता-प्रोवाइडर रूट
• ट्रायल कंप्यूट खपत
• मॉडल के अनुसार प्रति रन लागत
• कोहोर्ट के अनुसार विफलता दर और पूर्णता दर

यह उस डेटाबेस सच्चाई को आसपास के सिस्टम के साथ भी जोड़ सकता है।

हमारा Morning Brief Plausible, Axiom, Sentry, Google Ads, GitHub और अन्य संचालन स्रोतों से खींचता है। डेटाबेस हमें बताता है कि उपयोगकर्ताओं और संगठनों ने क्या किया। Plausible हमें बताता है कि साइट पर क्या हुआ। PostHog प्रोडक्ट-इवेंट संदर्भ में मदद कर सकता है। Axiom हमें बताता है कि लॉग और रिक्वेस्ट पथ में क्या हुआ। Sentry त्रुटियाँ पकड़ता है। Stripe और Clerk बिलिंग और पहचान समझाने में मदद करते हैं। GitHub इंजीनियरिंग थ्रूपुट दिखाता है।

मुद्दा हर टूल को SQL से बदलना नहीं है। मुद्दा एजेंट को उन तथ्यों को जोड़ने देना है जिनकी संस्थापक वास्तव में परवाह करते हैं।

उदाहरण के लिए:

कल भुगतान वाले Google ने ऑर्गेनिक से ज़्यादा ट्रैफ़िक भेजा। क्या वे उपयोगकर्ता वास्तव में पहले रन तक पहुँचे, या वे फ़नल के शीर्ष पर रुक गए?

या:

हमने ट्रायल-दुरुपयोग गश्त बदली। क्या नए ट्रायल खातों ने अपने पहले कुछ घंटों में कम कंप्यूट जलाया?

या:

यह मॉडल रूट प्रति रन सस्ता है। क्या यह वास्तविक ऐतिहासिक चैट उपयोग में दिखता है, या केवल मूल्य-निर्धारण सिद्धांत में?

वे डैशबोर्ड सवाल नहीं हैं। वे संचालन सवाल हैं। वे हफ़्ते-दर-हफ़्ते, कभी-कभी दिन-दर-दिन बदलते हैं। सुरक्षित डेटाबेस एक्सेस वाला एक एजेंट हर बार इंजीनियरिंग से एक नया व्यू बनाने को कहे बिना उनका जवाब दे सकता है।

एक वास्तविक उदाहरण: रिटेंशन और बाहरी उपयोगकर्ता हेल्थ

हमारे दैनिक आंतरिक विश्लेषणों में से एक पिछले 24 घंटों में बाहरी उपयोगकर्ता हेल्थ को देखता है।

रिपोर्ट MaskDB से शुरू होती है, फिर एक सख़्त बहिष्करण सेट लागू करती है। आंतरिक VM0 संगठन हटा दिए जाते हैं। Clerk-बैन किए गए या लॉक किए गए स्पैम संगठन हटा दिए जाते हैं। वही बहिष्करण सेट हर जगह लागू होता है, जिसमें रजिस्ट्रेशन गिनती और रिटेंशन कोहोर्ट शामिल हैं, ताकि हर भाजक ऑडिट-योग्य बना रहे।

वहाँ से, एजेंट एक संक्षिप्त संचालन रिपोर्ट तैयार कर सकता है:

• रन और सक्रिय बाहरी संगठन
• पूर्णता दर
• वेब, CLI, शेड्यूल और गैर-Zero रूट में ट्रिगर मिश्रण
• मॉडल मिश्रण
• प्रोवाइडर मोड
• भुगतान वाले संगठनों की गतिविधि
• निष्क्रिय भुगतान वाले संगठन
• नए भुगतान वाले साइनअप और ट्रायल कर रहे संगठन
• चर्न निगरानी
• 30-दिन उपयोगकर्ता विभाजन
• रजिस्ट्रेशन-से-रन रिटेंशन
• पहले-रन रिटेंशन

यह बिल्कुल वैसी ही रिपोर्ट है जिसकी एक संस्थापक टीम को ज़रूरत होती है। इसमें कच्चे प्रॉम्प्ट की ज़रूरत नहीं है। इसमें कच्चे ईमेल की ज़रूरत नहीं है। इसमें प्रोडक्शन राइट एक्सेस की ज़रूरत नहीं है।

इसमें प्रोडक्ट तथ्यों को सही तरीके से जोड़ने की क्षमता की ज़रूरत है।

एक रन में, एजेंट ने पाया कि सक्रिय बाहरी संगठनों की एक छोटी संख्या ज़्यादातर वॉल्यूम चला रही थी, कि कई भुगतान वाले संगठन शांत हो गए थे, और कि हाल के रजिस्ट्रेशन कोहोर्ट ने एक तीव्र एक्टिवेशन क्लिफ़ दिखाया जो संभवतः स्पैम रजिस्ट्रेशन द्वारा भाजक को बढ़ाने के कारण था। ये वे चीज़ें हैं जो एक संस्थापक को जल्दी देखनी चाहिए, हफ़्तों बाद डैशबोर्ड समीक्षा में नहीं।

एक दूसरा उदाहरण: ट्रायल दुरुपयोग का अर्थशास्त्र

मास्क्ड प्रोडक्ट डेटा उन सवालों के लिए भी उपयोगी है जो क्लासिक BI चार्ट नहीं हैं।

जब हमने ट्रायल दुरुपयोग को देखा, तो उपयोगी मेट्रिक कुल खर्च किया गया कंप्यूट नहीं था। कुल खर्च पुराने खातों की ओर झुका हुआ होगा, क्योंकि उनके पास क्रेडिट खपत करने के लिए ज़्यादा समय था। बेहतर सवाल था:

एक नया खाता साइनअप के बाद अपने पहले कुछ घंटों में कितना ट्रायल कंप्यूट जलाता है?

MaskDB का उपयोग करते हुए, एजेंट ने रजिस्ट्रेशन के बाद मेल खाने वाली विंडो में कंप्यूट खपत मापी। इसने उपयोग इवेंट से क्रेडिट खपत, संगठन मेटाडेटा से रजिस्ट्रेशन टाइमस्टैम्प, और ट्रायल अर्थशास्त्र को भुगतान उपयोग से अलग करने के लिए सब्सक्रिप्शन स्थिति का उपयोग किया।

गश्त लाइव होने के बाद, साइनअप के बाद पहले घंटों में जलाया गया औसत ट्रायल कंप्यूट 80% से ज़्यादा गिर गया। भारी-खपत वाली पूँछ लगभग गायब हो गई। 90वें पर्सेंटाइल पर, पहले-घंटों का ट्रायल कंप्यूट लगभग $4.05 से लगभग $0.26 तक गिर गया, यानी 94% की गिरावट।

वह संख्या केवल एक एनालिटिक्स बिंदु नहीं है। यह व्यवसाय के संचालन दृष्टिकोण को बदल देती है। यह संस्थापक टीम को बताती है कि दुरुपयोग का न केवल पता लगाया जा रहा था, बल्कि ट्रायल का यूनिट अर्थशास्त्र सही दिशा में बढ़ रहा था।

और यह इसलिए संभव था क्योंकि डेटाबेस में सच्चाई थी, जबकि मास्क्ड ब्रांच ने उस सच्चाई का विश्लेषण करना एक एजेंट के लिए सुरक्षित बना दिया।

एक तीसरा उदाहरण: वास्तविक प्रोडक्ट में मॉडल लागत

मूल्य-निर्धारण पृष्ठ और बेंचमार्क शीट उपयोगी हैं, लेकिन वे उस सवाल का जवाब नहीं देते जिसकी संस्थापक वास्तव में परवाह करते हैं:

वास्तविक रन में, हमारे वास्तविक प्रोडक्ट में इस मॉडल की लागत क्या है?

MaskDB का उपयोग करते हुए, एजेंट ने रन रिकॉर्ड को रन के समय चुने गए मॉडल के साथ जोड़कर और उपयोग इवेंट से चार्ज किए गए क्रेडिट को एकत्र करके ऐतिहासिक चैट रन की तुलना की।

वह भेद मायने रखता है। आपको उपयोगकर्ता के वर्तमान डिफ़ॉल्ट मॉडल प्रोवाइडर का उपयोग करके ऐतिहासिक रन का श्रेय नहीं देना चाहिए, क्योंकि डिफ़ॉल्ट बदलते हैं। रन के समय चुना गया मॉडल सच्चाई का स्रोत है।

हमारे विश्लेषण में, DS v4 Pro की प्रति चैट रन माध्य मॉडल-क्रेडिट लागत Sonnet की लगभग 49% थी। दूसरे शब्दों में, वास्तविक माध्य चैट रन उस रूट पर लगभग 51% सस्ता था।

फिर से, यह संस्थापक-स्तरीय BI है। यह प्रोडक्ट व्यवहार, इंफ्रास्ट्रक्चर लागत और मॉडल रणनीति को जोड़ता है। इसमें एक नए वेयरहाउस की ज़रूरत नहीं है। इसमें सही रिलेशनल डेटा तक सुरक्षित एक्सेस की ज़रूरत है।

यह वेयरहाउस का स्थायी विकल्प नहीं है

एक बिंदु आता है जहाँ एक कंपनी को अधिक औपचारिक डेटा स्टैक की ज़रूरत होती है।

जब मेट्रिक्स को मज़बूत सिमेंटिक गवर्नेंस की ज़रूरत हो, जब कई टीमें समान परिभाषाओं पर निर्भर हों, जब ऐतिहासिक बैकफ़िल जटिल हो जाएँ, जब डैशबोर्ड संचालन प्रणाली का हिस्सा बन जाएँ, तब एक वेयरहाउस या लेकहाउस सही जवाब हो सकता है।

लेकिन कई स्टार्टअप उस जवाब तक बहुत जल्दी पहुँच जाते हैं।

यदि आप एक छोटी संस्थापक टीम हैं, तो आपके पहले BI सिस्टम को आपको सवालों के जवाब देने में मदद करनी चाहिए, न कि बनाए रखने के लिए एक दूसरा प्रोडक्ट बनाना चाहिए। एक मास्क्ड डेटाबेस वह पुल हो सकता है। यह यह दिखावा नहीं कर रहा है कि डेटा मॉडलिंग मायने नहीं रखती। यह पहचान रहा है कि प्रोडक्ट डेटाबेस में पहले से ही वे संबंध हैं जिनकी आपको अगले निर्णयों के सेट के लिए ज़रूरत है।

एजेंट निर्णय की ज़रूरत को नहीं हटाता। यह विश्लेषण के पहले संस्करण को चलाने में सस्ता बना देता है।

संस्थापक टीमों के लिए पैटर्न

पैटर्न सरल है:

1. प्रोडक्ट डेटाबेस को सच्चाई का पहला स्रोत मानें।
2. कभी भी एजेंट को कच्चा प्रोडक्शन उजागर न करें।
3. एक हाथ से बनाए गए नमूना डेटासेट के बजाय एक प्रोडक्शन-जैसी ब्रांच का उपयोग करें।
4. एक्सेस से पहले संवेदनशील कॉलम को स्टैटिक रूप से मास्क करें।
5. अपारदर्शी जॉइन पहचानकर्ताओं को संरक्षित रखें ताकि विश्लेषण फिर भी काम करे।
6. ब्रांच को एक रीड-ओनली भूमिका के माध्यम से उजागर करें।
7. एजेंट को मास्क्ड DB और आसपास के टूल में विश्लेषक लूप चलाने दें।

यह एक संस्थापक टीम को पहले एक पूर्ण डेटा प्लेटफ़ॉर्म बनाए बिना एक उपयोगी संचालन प्रणाली देता है।

यह एक साफ़ सुरक्षा स्थिति भी बनाता है। एजेंट के पास एक कठोर सीमा होती है। जो डेटाबेस यह देखता है वह पहले ही ट्रांसफ़ॉर्म हो चुका होता है। जिस भूमिका का यह उपयोग करता है वह लिख नहीं सकती। जो रिपोर्ट यह तैयार करता है उन्हें हैश किए गए या एकत्रित पहचानकर्ताओं तक सीमित किया जा सकता है।

यही वह संतुलन है जो हम VM0 में चाहते थे: गोपनीयता और सुरक्षा को आधार के रूप में, समझौते के रूप में नहीं, जबकि संस्थापक टीम को व्यवसाय समझने का एक बहुत तेज़ तरीका दिया जाए।

डेटा लेक बनाने से पहले, यह पूछें कि क्या आपके प्रोडक्ट डेटाबेस की एक मास्क्ड, रीड-ओनली ब्रांच आपकी टीम के अगले 20 सवालों का जवाब दे सकती है।

हमारे लिए, वही BI तक का तेज़ रास्ता था।

स्रोत

• Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
• PostgreSQL Anonymizer का Neon फ़ोर्क: https://github.com/neondatabase/postgresql_anonymizer