प्रत्येक Mythex ॲपला स्वतःचा डेटाबेस का मिळतो

Mythex वर तुम्ही बनवलेल्या ॲपला डेटा साठवायचा असेल — साइनअप, बुकिंग, ऑर्डर — तेव्हा Mythex त्या प्रोजेक्टला स्वतःचा Postgres डेटाबेस देते. शेअर्ड डेटाबेसमधील टेबल नव्हे, किंवा कोणा दुसऱ्याच्या शेजारचा schema नव्हे: एक वेगळा डेटाबेस, मागणीनुसार तयार केलेला, जो कोणी वापरत नसताना झोपतो. आम्ही तो असा का बनवला आणि त्याचा खर्च काय आहे ते इथे आहे.

तुम्हाला काय मिळते

तुम्ही डेटा मागता ("waitlist ईमेल साठवा", "bookings साठवा") किंवा /database कमांड वापरता, तेव्हा Mythex:

• प्रोजेक्टसाठी एक समर्पित Postgres डेटाबेस तयार करते (सध्या Postgres 17),
• कनेक्शन तपशील तुमच्या workspace मध्ये आणि तुमच्या प्रकाशित ॲपमध्ये environment variables म्हणून इंजेक्ट करते, त्यामुळे ते तुमच्या कोडमध्ये कधीच दिसत नाहीत, आणि
• agent ला तुमच्यासाठी टेबल्स तयार करण्याची आणि डेटा वाचण्याची व लिहिण्याची परवानगी देते.

तोच डेटाबेस live preview आणि प्रकाशित ॲप दोन्ही वापरतात. तो 5 निष्क्रिय मिनिटांनी झोपतो आणि पुढील query वर जागा होतो. नवीन डेटाबेस लहान सुरू होतात आणि भार वाढला तर मोठे होऊ शकतात, एक ceiling सह, त्यामुळे एखादी बेफाम query अमर्याद वाढू शकत नाही. अधिक माहितीसाठी database docs पहा.

एकच मोठा शेअर्ड डेटाबेस का नाही?

प्रत्येक row कोणत्या ॲपची आहे हे सांगणाऱ्या column सह एक शेअर्ड डेटाबेस चालवायला स्वस्त आणि चालवायला सोपा असतो. आम्ही चार कारणांसाठी ते न करण्याचे ठरवले.

1. तुम्हाला विश्वास ठेवावा न लागणारे अलगीकरण

AI-लिहिलेल्या कोडमध्ये चुका होतात. शेअर्ड डेटाबेसमध्ये, एका ॲपच्या एका query मधून WHERE app_id = … गेला तर दुसऱ्या ग्राहकाचा डेटा वाचला किंवा overwrite होऊ शकतो. प्रत्येक ॲपसाठी स्वतंत्र डेटाबेस असल्यास, पोहोचात दुसऱ्या ग्राहकाचा डेटा नसतो — एखादा bug स्वतःच्या ॲपमध्येच राहतो.

2. ते खरे Postgres आहे, मालकीचा स्तर नाही

तुमचे ॲप सामान्य connection string वापरून प्रमाणित Postgres शी बोलते. Postgres सह काम करणारी कोणतीही library, ORM किंवा tool इथेही काम करते. तुम्ही दुसरीकडे चालवण्यासाठी तुमचा प्रोजेक्ट export केला, तर त्याला Postgres डेटाबेस हवा असतो — प्रत्येक hosting प्रदाता देतो तेच — Mythex-विशिष्ट API नव्हे.

3. प्रत्येक ॲप गरजेनुसार आकार घेऊ शकते

एका ॲपला bookings टेबल हवे असते ज्यात वेळ-स्लॉटवर unique constraint असतो; दुसऱ्याला उत्पादनांवर full-text search हवे असते. स्वतःचा डेटाबेस असल्यामुळे प्रत्येक ॲपचा schema आणि migrations त्याचेच असतात. कोणालाही सर्वांच्या सामाईक किमान डिझाइनमध्ये बसवावे लागत नाही.

4. खर्च वापराचे अनुसरण करतो

प्रत्येक डेटाबेस स्वतंत्रपणे झोपत असल्यामुळे, कोणी न वापरणारा ॲप जवळजवळ काहीच खर्च करत नाही, आणि व्यस्त ॲपचा खर्च स्वतःच्या ओळीत दिसतो. प्रकाशित डेटाबेसचा वापर डेटाबेसने प्रत्यक्षात मोजलेल्या गोष्टींवरून बिल केला जातो — हे बिलिंग कसे काम करते.

तोटे

हे डिझाइन फुकट नाही:

• Cold starts. शांत कालावधीनंतर पहिल्या query वर झोपलेला डेटाबेस जागा होण्यास वेळ घेतो. बहुतेक ॲप्ससाठी हे जेमतेम जाणवते; कोणत्याही वेळी लगेच उत्तर देणे आवश्यक असलेल्या ॲपसाठी तो विचार करण्यासारखा आहे.
• जागा पण सक्रिय असतानाचा खर्च. कोणी query करत असताना डेटाबेस जागा राहतो. दर काही सेकंदांनी आपल्या डेटाबेसला poll करणारा ॲप त्याला दिवसभर जागे ठेवतो, आणि मागणीनुसार डेटा लोड करणाऱ्या ॲपपेक्षा जास्त खर्च करतो. तुमचे ट्रॅफिक अपेक्षेपेक्षा जास्त दिसत असेल, तर सहसा हेच कारण असते — AI ला poll करणे थांबवून गरज असेल तेव्हा डेटा लोड करायला सांगा.
• आमच्यासाठी जास्त हलणारे भाग. हजारो डेटाबेस तयार करणे, त्यांचा मागोवा ठेवणे आणि स्वच्छ करणे एकापेक्षा जास्त काम आहे. ते आमचे ओझे आहे, तुमचे नाही.

तुम्ही डेटाबेससाठी नवीन असाल तर

डेटाबेस म्हणजे जिथे ॲप लक्षात ठेवायला हवे ते साठवते. कल्पना नवीन असेल, तर डेटाबेस म्हणजे काय आणि Postgres म्हणजे काय ने सुरुवात करा. डेटा साठवणारे काहीतरी बनवण्यास तयार झाल्यावर, AI ने ॲप कसे बनवायचे डेटा जोडणे कसे चालते ते सांगते.