PostgreSQL + Querri
आपके प्रोडक्ट के अकाउंट, यूज़र और इवेंट पहले से Postgres में हैं। Querri से ऑप्स, फ़ाइनेंस और कस्टमर टीमें उनके बारे में आम भाषा में पूछ सकती हैं, बिलिंग और CRM के साथ, और किसी को प्रोडक्शन पर क्वेरी नहीं लिखनी पड़ती।
Querri आपका PostgreSQL डेटा सिर्फ़ पढ़ता है और कभी कोई पंक्ति नहीं बदलता। आपका पासवर्ड एक सुरक्षित फ़ॉर्म में जाता है जिसे एजेंट कभी नहीं देखता। SOC 2 Type II, HIPAA और ISO 27001:2022 प्रमाणित।
PostgreSQL रिपोर्टिंग मुश्किल क्यों हो जाती है
इंजीनियरिंग टीमें और उन पर निर्भर लोग एक जैसी अड़चन बताते हैं। Postgres अपना काम अच्छी तरह करता है। अड़चन डेटाबेस और सवाल पूछने वाले व्यक्ति के बीच है।
जवाब सिर्फ़ वही लोग निकाल सकते हैं जो SQL और स्कीमा जानते हैं, और वही प्रोडक्ट शिप कर रहे होते हैं। कस्टमर सक्सेस और फ़ाइनेंस एक क्वेरी के लिए कतार में इंतज़ार करते हैं, और जवाब किसी स्प्रेडशीट में चिपका दिया जाता है।
प्रोडक्शन डेटाबेस पर भारी रिपोर्टिंग क्वेरी ग्राहकों के ट्रैफ़िक के साथ CPU, मेमोरी और लॉक साझा करती है। कोई नहीं चाहता कि उसके डैशबोर्ड की वजह से चेकआउट धीमा हो।
Hot standby पर, जो क्वेरी replication से टकराती है, वह तब रद्द हो जाती है जब replay, max_standby_streaming_delay से ज़्यादा इंतज़ार कर चुका हो, जिसका डिफ़ॉल्ट 30 सेकंड है। एक बड़ी एनालिटिकल रीड आधे रास्ते में फ़ेल हो सकती है।
स्टेटस integer के रूप में सेव, सेटिंग्स JSONB में ठुँसी हुई, soft-delete की गई पंक्तियाँ, ग्राहकों के बीच मिले हुए टेस्ट अकाउंट। टेबल को सही ढंग से पढ़ने के लिए वह जानकारी चाहिए जो कोडबेस में रहती है।
अपडेट पुराने मान को मिटा देता है, इसलिए पिछले महीने का प्लान या स्टेटस गायब हो जाता है, जब तक किसी ने हिस्ट्री टेबल न बनाई हों। बिलिंग, CRM और सपोर्ट डेटा दूसरे सिस्टम में होते हैं जिनसे डेटाबेस जुड़ नहीं सकता।
जिनका जवाब आखिरकार मिल सकता है
हर एक ऐसी मांग है जो ऑप्स, फ़ाइनेंस और कस्टमर टीमें हर हफ़्ते इंजीनियरिंग को भेजती हैं, साथ में यह कि वह क्यों अटकती है, और Querri उसे कैसे संभालता है।
मुश्किल क्यों है
भुगतान वाली सीटें subscription की पंक्ति में होती हैं, लॉगिन लाखों पंक्तियों वाली एक events टेबल में, और "सक्रिय" का मतलब पूछने वाली हर टीम के लिए अलग होता है।
मुश्किल क्यों है
जवाब के लिए साइनअप की तारीख, पहला अहम इवेंट, और "अहम" की ऐसी परिभाषा चाहिए जिस पर प्रोडक्ट और ग्रोथ टीम सच में सहमत हों।
Querri के साथ
इस पड़ाव को एक बार फ़ैक्ट्स और नियम में लिख दें, और Querri हफ़्ते, प्लान और चैनल के हिसाब से उस तक पहुँचने का समय मापता है। साइनअप से पहली वैल्यू तक की प्लेबुक सेटअप कदम-दर-कदम समझाती है।
मुश्किल क्यों है
ट्रायल की गतिविधि Postgres में है और डील CRM में। किसी वर्कस्पेस को कंपनी से मिलाना हाथ से की जाने वाली खोज है, जिसके लिए सेल्स के पास कभी समय नहीं होता।
Querri के साथ
Postgres के साथ HubSpot या Salesforce कनेक्ट करें। Querri से कहें कि ईमेल डोमेन के आधार पर वर्कस्पेस को कंपनियों से मिलाए। जवाब बताता है कि मिलान कैसे हुआ और उन व्यस्त ट्रायल की सूची देता है जिनकी कोई खुली डील नहीं है।
मुश्किल क्यों है
कुल आँकड़े में इस्तेमाल की गिरावट सामान्य लगती है। यह तभी दिखती है जब हर अकाउंट की तुलना उसके अपने अतीत से हो, और कोई भी हर ग्राहक के लिए हर दिन वह क्वेरी नहीं चलाता।
Querri के साथ
अकाउंट की गतिविधि को एक KPI के रूप में रखें, और रात के monitors उसे उसके अपने इतिहास से परखते हैं और फिसलते अकाउंट आपके Inbox में छोड़ देते हैं। जोखिम वाले रिन्यूअल की प्लेबुक CRM से रिन्यूअल की तारीखें जोड़ती है।
मुश्किल क्यों है
स्टेटस 3 का मतलब रद्द, deleted_at का मतलब हटाया गया, और अंदरूनी टेस्ट अकाउंट ग्राहकों जैसे दिखते हैं। इनमें से एक भी गलत हुआ तो चर्न रेट गलत हो जाता है।
Querri के साथ
Querri को नियम सीधे शब्दों में बताएँ, जैसे "हमारे अपने ईमेल डोमेन वाले अकाउंट छोड़ दो।" उसके बाद हर जवाब उनका पालन करता है, और गिनने से पहले Querri डेटा को पहले जाँचता है कि कहीं डुप्लिकेट या खाली मान तो नहीं।
मुश्किल क्यों है
सोमवार को कोई एक सेव की हुई क्वेरी चलाता है, नतीजा पिछले हफ़्ते की वर्कबुक में कॉपी करता है और फ़ॉर्मैटिंग हाथ से ठीक करता है।
Querri के साथ
आँकड़ों को एक बार प्रोजेक्ट के रूप में बनाएँ। एक शेड्यूल उसे सबसे नए सिंक पर दोबारा चलाता है और फ़ॉर्मैट की हुई वर्कबुक ईमेल करता है। देखें रिपोर्ट्स और ऑटोमेशन।
मुश्किल क्यों है
ग्राहकों के लिए रिपोर्टिंग का मतलब आमतौर पर एक इंजीनियरिंग प्रोजेक्ट होता है: एक चार्टिंग लाइब्रेरी, एक API, और सावधानी से फ़िल्टरिंग ताकि कोई ग्राहक दूसरे की पंक्तियाँ न देखे।
Querri के साथ
पूछकर डैशबोर्ड बनाएँ, फिर Embed से उसे अपने ऐप में लगाएँ। हर ग्राहक के लिए एक रो फ़िल्टर, जो वर्कस्पेस और एक्सेस में एक बार सेट होता है, हर ग्राहक को उसके अपने डेटा तक सीमित रखता है।
मुश्किल क्यों है
किसी असिस्टेंट को connection string देने का मतलब है कि वह आपके स्कीमा का अंदाज़ा लगाता है, और एक क्रेडेंशियल ऐसी जगह पहुँच जाता है जहाँ उसे नहीं होना चाहिए।
Querri के साथ
Querri को Claude या ChatGPT से जोड़ें। जवाब आपकी Library से आते हैं, आपकी टीम की तय की हुई परिभाषाओं के साथ, और उतने तक सीमित जितना हर व्यक्ति Querri में देख सकता है। कोई डेटाबेस क्रेडेंशियल Querri से बाहर नहीं जाता।
PostgreSQL और बाकी सब
Postgres जानता है कि किसने साइन अप किया और क्या किया। CRM जानता है कि सेल्स किससे बात कर रही है, अकाउंटिंग जानती है कि किसने भुगतान किया, और सपोर्ट जानता है कि कौन अटका है। चारों एक Library से कनेक्ट हों, तो किसी अकाउंट के बारे में एक ही सवाल हर एक से जानकारी ले सकता है।
PostgreSQL इनके साथ अच्छा काम करता है
ऐसे जवाब जिनके पीछे आप खड़े रह सकें
"सितंबर में कितने ग्राहक चर्न हुए?" में सितंबर में किए गए कैंसलेशन गिने जा सकते हैं, या वे प्लान जो भुगतान की अवधि खत्म होने के बाद सच में तभी बंद हुए। दोनों का बचाव किया जा सकता है, और ये शायद ही कभी मेल खाते हैं। Querri एक देता है, बताता है कि कौन-सा, और दूसरा भी दिखाता है, ताकि फ़ाइनेंस और प्रोडक्ट ग्राहकों पर बहस करें, क्वेरी पर नहीं। देखें जवाब कैसे काम करते हैं।
जागें तो जानें क्या बदला
रात भर Querri हर KPI की तुलना उसके अपने रिकॉर्ड से करता है और ऐसे बदलाव ढूँढता है जिनके बारे में किसी ने नहीं पूछा। सुबह तक नतीजे आपके Inbox में होते हैं, और आपकी मंज़ूरी के बिना Querri उनमें से किसी पर कोई कदम नहीं उठाता।
कस्टम PostgreSQL डैशबोर्ड
बताएँ कि डैशबोर्ड में क्या दिखना चाहिए, या उस डैशबोर्ड के स्क्रीनशॉट से शुरू करें जिस पर आपकी टीम पहले से निर्भर है। चार्ट उसी Library से पढ़ते हैं जिससे चैट, इसलिए प्रोडक्ट इस्तेमाल राजस्व और सपोर्ट डेटा के साथ दिख सकता है, और हर टीम या ग्राहक को उन्हीं पंक्तियों तक सीमित किया जा सकता है जो उसे देखनी चाहिए।
ऐसी रिपोर्ट्स जिन्हें दोबारा बनाना बंद कर सकें
साइनअप से पहली अहम गतिविधि तक के दिन, साइनअप के हफ़्ते और चैनल के हिसाब से।
प्लेबुक पढ़ेंइस्तेमाल, सीटें और सपोर्ट का भार, हर अकाउंट के लिए एक स्कोर में, हर रात निगरानी में।
प्लेबुक पढ़ेंजल्द रिन्यू होने वाले अकाउंट जिनकी ऐप में गतिविधि घट रही है।
प्लेबुक पढ़ेंभुगतान वाली सीटें बनाम सक्रिय सीटें, हर अकाउंट और प्लान के लिए, इतिहास के साथ एक KPI के रूप में।
KPIs देखेंसाइनअप, एक्टिवेशन और सक्रिय अकाउंट, हर हफ़्ते फ़ॉर्मैट की हुई वर्कबुक के रूप में ईमेल।
Excel टूल्स देखेंहर ग्राहक के लिए एक वर्शन, शेड्यूल पर भेजा गया, हर एक में सिर्फ़ उसी ग्राहक की पंक्तियाँ।
रिपोर्ट्स देखेंक्या-क्या आता है
आपके तय किए शेड्यूल पर Querri चुनी हुई टेबल और व्यू अपने स्टोरेज में कॉपी करता है। हर सवाल का जवाब उसी कॉपी से दिया जाता है, इसलिए कोई भी सवाल आपके डेटाबेस पर नहीं चलता। यह सिर्फ़ वही सिंक कर सकता है जो आपका कनेक्ट किया गया Postgres यूज़र पढ़ सकता है।
आप क्या सिंक कर सकते हैं
डिफ़ॉल्ट रूप से पूरा रिफ़्रेश। Incremental शेड्यूल पर, updated_at जैसा कोई cursor कॉलम चुनें और Querri सिर्फ़ पिछले रन के high-water mark के बाद की पंक्तियाँ लाता है, हर घंटे तक। डिलीट की गई पंक्तियाँ पूरे रिफ़्रेश पर हटती हैं।
पंक्तियाँ टुकड़ों में Parquet में स्ट्रीम होती हैं, बीच में रुका पूरा सिंक वहीं से फिर शुरू होता है जहाँ रुका था, और जब तक आप खुद सीमा न लगाएँ, पंक्तियों की कोई सीमा नहीं है। रीड हर टेबल के लिए कुछ ही कनेक्शन इस्तेमाल करती हैं और हल्की रहने के लिए ट्यून की गई हैं, चाहे primary हो या read replica।
Querri आपके डेटाबेस को read-only मोड में जोड़ता है, इसलिए यह कुछ भी insert, update या delete नहीं कर सकता। यह कभी कोई पंक्ति या टेबल नहीं बदलता।
आप यूज़रनेम और पासवर्ड एक सुरक्षित फ़ॉर्म में टाइप करते हैं; वे एन्क्रिप्ट करके सेव होते हैं और Connector Agent उन्हें कभी नहीं देखता। डिफ़ॉल्ट रूप से SSL ज़रूरी है।
PostgreSQL कैसे कनेक्ट करें
Connect खोलें और कहें "हमारा Postgres डेटाबेस कनेक्ट करो," या कैटलॉग से PostgreSQL चुनें।
होस्ट, डेटाबेस और यूज़रनेम, साथ में पोर्ट और पासवर्ड, एक सुरक्षित फ़ॉर्म में जिसे एजेंट कभी नहीं पढ़ता। एक read-only यूज़र, बेहतर हो तो replica पर, अच्छा विकल्प है।
फ़ायरवॉल के पीछे वाले डेटाबेस के लिए, VPN tunnel पैनल में अपनी OpenVPN प्रोफ़ाइल और सर्टिफ़िकेट जोड़ें। वे एन्क्रिप्ट करके सेव होते हैं।
एक स्कीमा चुनें और उसकी सारी टेबल लें या बस कुछ, ज़रूरत हो तो कस्टम SQL जोड़ें, और एक शेड्यूल सेट करें। आपके हाँ कहने से पहले एजेंट कुछ भी लोड नहीं करता।
पहला सिंक आपकी Library में आते ही, एक्सेस वाला कोई भी व्यक्ति उससे सवाल पूछ सकता है, चार्ट बना सकता है या शेड्यूल कर सकता है।
PostgreSQL FAQ
Connect पेज पर Connector Agent से PostgreSQL के लिए कहें, या कैटलॉग में उसे चुनें। सुरक्षित फ़ॉर्म में होस्ट, डेटाबेस, यूज़रनेम और पासवर्ड डालें (पोर्ट डिफ़ॉल्ट रूप से 5432 है और SSL चालू है), एक स्कीमा और टेबल चुनें, फिर लोड और शेड्यूल मंज़ूर करें।
आप हर कनेक्शन के लिए एक स्कीमा चुनते हैं, फिर उसकी सारी टेबल लेते हैं या कुछ खास टेबल चुनते हैं। Base tables, views, materialized views और foreign tables सभी सूची में आते हैं, और आप अपनी SQL क्वेरी को अतिरिक्त सोर्स के रूप में जोड़ सकते हैं। Querri सिर्फ़ वही देखता है जो कनेक्ट किए गए Postgres यूज़र को पढ़ने की अनुमति है।
पूरा रिफ़्रेश रोज़, हर हफ़्ते या हर महीने के शेड्यूल पर चलता है। Incremental शेड्यूल हर घंटे तक चल सकता है और सिर्फ़ वे पंक्तियाँ लाता है जिनका cursor कॉलम, जैसे updated_at, पिछले रन से नया है। हाथ से शुरू किया गया सिंक पूरा सिंक होता है। Incremental रन डिलीट की गई पंक्तियाँ नहीं देखते; पूरा रिफ़्रेश देखता है।
नहीं। Querri आपका डेटा सिर्फ़ पढ़ता है। यह डेटाबेस को read-only मोड में जोड़ता है, इसलिए यह कोई पंक्ति insert, update या delete नहीं कर सकता, न ही टेबल बदल सकता है। ज़्यादा भरोसे के लिए, ऐसे Postgres यूज़र से कनेक्ट करें जिसके पास सिर्फ़ SELECT अधिकार हों।
सवाल कभी आपके डेटाबेस पर नहीं चलते; वे उस कॉपी पर चलते हैं जिसे Querri सिंक करता है। सिंक खुद हल्का रहने के लिए ट्यून किया गया है, हर टेबल के लिए कुछ ही कनेक्शन के साथ, और यह कब चले यह आप चुनते हैं। आप इसे read replica पर भी पॉइंट कर सकते हैं ताकि primary को बिल्कुल न छुआ जाए।
हाँ। primary के बजाय replica का होस्ट डालें। ध्यान रखें कि hot standby, replication से टकराने वाली क्वेरी को max_standby_streaming_delay के बाद रद्द कर देता है, जो डिफ़ॉल्ट रूप से 30 सेकंड है, इसलिए किसी बड़ी टेबल के सिंक के लिए यह सीमा बढ़ानी पड़ सकती है। hot_standby_feedback चालू करने से vacuum cleanup की वजह से होने वाले रद्दीकरण रुक जाते हैं, बदले में primary पर कुछ bloat बढ़ता है।
Querri सिर्फ़ वही स्कीमा और टेबल सिंक कर सकता है जिन्हें कनेक्ट किया गया Postgres यूज़र पढ़ सकता है, और स्कीमा पिकर सिर्फ़ वे स्कीमा दिखाता है जिन पर उस यूज़र के पास USAGE है। डेटा Querri में आने के बाद, हर व्यक्ति क्या देखता है यह Querri की रो-लेवल एक्सेस और शेयरिंग सेटिंग्स तय करती हैं; Postgres roles हर व्यक्ति के लिए साथ नहीं आते।
कनेक्शन फ़ॉर्म में VPN tunnel पैनल इस्तेमाल करें और अपनी OpenVPN प्रोफ़ाइल, CA सर्टिफ़िकेट, क्लाइंट सर्टिफ़िकेट और प्राइवेट की अपलोड करें। चारों एन्क्रिप्ट करके सेव होते हैं। PostgreSQL के लिए अभी SSH tunnel समर्थित नहीं हैं, इसलिए जो डेटाबेस इंटरनेट से नहीं पहुँचे जा सकते, उनके लिए VPN ही रास्ता है।
दोनों को कनेक्ट करें, और Querri उन्हें Library में किसी साझा key, जैसे अकाउंट ID या ईमेल डोमेन, के आधार पर जोड़ता है। फिर आप प्रोडक्ट इस्तेमाल को रिन्यूअल की तारीखों, अकाउंट मालिकों और पाइपलाइन के साथ रख सकते हैं, और जब मिलान पक्का न हो तो जवाब चुपचाप अंदाज़ा लगाने के बजाय यह बताता है।
Postgres और HubSpot कनेक्ट करें, और Querri ऐप के वर्कस्पेस या यूज़र का HubSpot के संपर्कों और कंपनियों से मिलान करता है। इससे आप देख सकते हैं कि किन सक्रिय ट्रायल की कोई डील नहीं है, कौन-से लीड कभी एक्टिवेट हुए, और कौन-से मार्केटिंग सोर्स ऐसे यूज़र लाते हैं जो टिके रहते हैं।
दोनों को कनेक्ट करें, और Querri सपोर्ट बातचीत को उस गतिविधि के साथ रखता है जो हर अकाउंट आपके प्रोडक्ट में करता है। पूछें कि किन फ़ीचर की वजह से सबसे ज़्यादा बातचीत होती है, या जो अकाउंट जल्दी सपोर्ट से संपर्क करते हैं वे बाकियों से तेज़ एक्टिवेट होते हैं या धीमे।
Querri को बताएँ कि कौन-सा इवेंट पहली वैल्यू माना जाए, और यह हर अकाउंट के साइनअप से उस इवेंट तक का समय हफ़्ते, प्लान या चैनल के हिसाब से मापता है। साइनअप से पहली वैल्यू तक की प्लेबुक कदम-दर-कदम समझाती है, और नतीजा एक KPI के रूप में चल सकता है जो अपना इतिहास रखता है।
Querri को नियम एक बार सिखाएँ: कौन-सा स्टेटस रद्द का मतलब है, कौन-सी पंक्तियाँ soft-delete हैं, कौन-से अकाउंट अंदरूनी हैं। उसके बाद हर गिनती उनका पालन करती है। जब चर्न का मतलब कैंसलेशन भी हो सकता है और खत्म हुए प्लान भी, तो Querri बताता है कि उसने कौन-सा अर्थ इस्तेमाल किया और दूसरा भी दिखाता है।
विश्लेषण को Querri में एक बार प्रोजेक्ट के रूप में बनाएँ, फिर उसे शेड्यूल करें। हर रन सबसे नया सिंक किया गया डेटा इस्तेमाल करता है और फ़ॉर्मैट की हुई Excel वर्कबुक ईमेल से भेजता है, या हर टीम या ग्राहक के लिए एक वर्शन, ताकि किसी को क्वेरी चलाकर नतीजे हाथ से चिपकाने न पड़ें।
हाँ। जो डैशबोर्ड आप चाहते हैं उसका वर्णन करें, या पहले से मौजूद किसी डैशबोर्ड के स्क्रीनशॉट से शुरू करें, और पूछकर उसे बदलें। उसमें Postgres के साथ बिलिंग, CRM और सपोर्ट डेटा मिल सकता है, और हर व्यक्ति या ग्राहक को उसकी अपनी पंक्तियों तक सीमित किया जा सकता है।
हाँ। Querri को Claude या ChatGPT से एक बार जोड़ें। असिस्टेंट आपकी Querri Library से, आपकी टीम की परिभाषाओं के साथ, हर व्यक्ति के अपने एक्सेस के तहत जवाब देता है, और उसे कभी डेटाबेस लॉगिन नहीं मिलता। यह उन्हीं परिभाषाओं से काम करता है जो आपके डैशबोर्ड इस्तेमाल करते हैं।
हर कनेक्शन एक स्कीमा पढ़ता है, इसलिए कई स्कीमा के लिए कई कनेक्शन चाहिए। कस्टम SQL incremental रूप से सिंक नहीं हो सकता, incremental सिर्फ़ शेड्यूल पर चलता है, और यह डिलीट की गई पंक्तियाँ नहीं पकड़ता। SSH tunnel नहीं है, require से आगे SSL सर्टिफ़िकेट की जाँच नहीं है, और change-data-capture स्ट्रीमिंग नहीं है; डेटा शेड्यूल पर आता है।
हाँ। अगर यूज़र Postgres के system catalogs नहीं पढ़ सकता, तो Querri एक सरल सूची पर आ जाता है। उस मोड में materialized views सूची में नहीं आते और कस्टम SQL क्वेरी स्वीकार नहीं की जातीं, इसलिए जिन टेबल और व्यू की ज़रूरत है उन्हें सीधे चुनें।
Querri, SOC 2 Type II, HIPAA और ISO 27001:2022 प्रमाणित है, और आपका डेटा कभी किसी मॉडल को ट्रेन करने में इस्तेमाल नहीं होता। कनेक्शन के लिए डिफ़ॉल्ट रूप से SSL ज़रूरी है, पासवर्ड और VPN फ़ाइलें एन्क्रिप्ट करके सेव होती हैं, Connector Agent उन्हें कभी नहीं देखता, और डेटाबेस read-only जुड़ा होता है।
और जानें
सेटअप में कुछ ही मिनट लगते हैं। Querri आपका डेटा सिर्फ़ पढ़ता है और कभी कोई पंक्ति नहीं बदलता।