हर Mythex ऐप को अपना डेटाबेस क्यों मिलता है

जब आप Mythex पर बनाए ऐप को डेटा सेव करना होता है, जैसे साइनअप, बुकिंग, ऑर्डर, तो Mythex उस प्रोजेक्ट को अपना Postgres डेटाबेस देता है। साझा डेटाबेस में कोई टेबल नहीं, किसी दूसरे के बगल में कोई स्कीमा नहीं: एक अलग डेटाबेस, माँग पर बनाया गया, जो कोई इस्तेमाल न करे तो सो जाता है। हमने इसे इसी तरह क्यों बनाया, और इसकी कीमत क्या है, यहाँ है।

आपको क्या मिलता है

जब आप डेटा माँगते हैं ("वेटलिस्ट के ईमेल सेव करो", "बुकिंग स्टोर करो") या /database कमांड इस्तेमाल करते हैं, तो Mythex:

• प्रोजेक्ट के लिए एक समर्पित Postgres डेटाबेस बनाता है (फ़िलहाल Postgres 17),
• कनेक्शन विवरण आपके वर्कस्पेस और पब्लिश किए गए ऐप में एनवायरनमेंट वेरिएबल के रूप में डालता है, ताकि वे कभी आपके कोड में न दिखें, और
• एजेंट को आपके लिए टेबल बनाने और डेटा पढ़ने-लिखने देता है।

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

एक बड़ा साझा डेटाबेस क्यों नहीं?

एक साझा डेटाबेस जिसमें एक कॉलम हो जो बताए कि हर पंक्ति किस ऐप की है, चलाने में सस्ता और संचालित करने में सरल है। हमने चार कारणों से उसे न चुनने का फ़ैसला किया।

1. ऐसी अलगाव जिस पर भरोसा नहीं करना पड़ता

AI से लिखा कोड गलतियाँ करता है। एक साझा डेटाबेस में, किसी एक ऐप की क्वेरी में एक छूटा हुआ WHERE app_id = … किसी दूसरे ग्राहक का डेटा पढ़ या overwrite कर सकता है। हर ऐप के लिए अलग डेटाबेस हो, तो किसी दूसरे ग्राहक का डेटा पहुँच में नहीं होता, और कोई बग अपने ही ऐप के भीतर रहता है।

2. यह असली Postgres है, कोई मालिकाना परत नहीं

आपका ऐप एक सामान्य कनेक्शन स्ट्रिंग से सामान्य Postgres से बात करता है। जो भी लाइब्रेरी, ORM या टूल Postgres के साथ काम करता है, वह यहाँ भी काम करता है। अगर आप अपना प्रोजेक्ट एक्सपोर्ट करके कहीं और चलाते हैं, तो वह एक Postgres डेटाबेस की अपेक्षा करता है, जो हर होस्टिंग प्रदाता देता है, न कि Mythex-विशिष्ट API।

3. हर ऐप अपनी ज़रूरत के अनुसार आकार ले सकता है

एक ऐप को टाइम स्लॉट पर unique constraint वाली bookings टेबल चाहिए; दूसरे को उत्पादों पर फ़ुल-टेक्स्ट सर्च चाहिए। अपने डेटाबेस के साथ, हर ऐप का स्कीमा और माइग्रेशन उसका अपना मामला है। कुछ भी सबसे कम-साझा डिज़ाइन में फ़िट करने की ज़रूरत नहीं।

4. लागत उपयोग का पालन करती है

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

इसकी कीमतें

यह डिज़ाइन मुफ़्त नहीं है:

• कोल्ड स्टार्ट। शांत अवधि के बाद पहली क्वेरी पर सोता डेटाबेस जागने में थोड़ा समय लेता है। ज़्यादातर ऐप्स के लिए यह मुश्किल से महसूस होता है; जो ऐप हर समय तुरंत जवाब देना ज़रूरी समझता है, उसके लिए यह विचारणीय है।
• जागते हुए भी लागत। जब तक कुछ उसे क्वेरी करता है, डेटाबेस जागता रहता है। जो ऐप हर कुछ सेकंड में अपना डेटाबेस पोल करता है, वह उसे दिन-रात जगाए रखता है और उस ऐप से ज़्यादा खर्च करता है जो माँग पर क्वेरी करता है। अगर आपका उपयोग अपेक्षा से ज़्यादा दिखे, तो आम तौर पर यही कारण होता है: AI से कहें कि पोल करना बंद करे और ज़रूरत पड़ने पर डेटा लोड करे।
• हमारी ओर अधिक चल रही चीज़ें। हज़ारों डेटाबेस बनाना, ट्रैक करना और साफ़ करना एक से ज़्यादा काम है। वह हमारी ज़िम्मेदारी है, आपकी नहीं।

अगर आप डेटाबेस में नए हैं

डेटाबेस वह जगह है जहाँ एक ऐप वह रखता है जो उसे याद रखना है। अगर यह विचार नया है, तो डेटाबेस क्या है और Postgres क्या है से शुरू करें। जब आप ऐसी चीज़ बनाने के लिए तैयार हों जो डेटा स्टोर करे, तो AI से ऐप कैसे बनाएँ में बताया गया है कि उसे कैसे जोड़ें।