ہر Mythex ایپ کو اپنا database کیوں ملتا ہے

جب آپ Mythex پر بنائی ہوئی ایپ کو ڈیٹا محفوظ کرنا ہو، جیسے sign-ups، bookings، orders، تو Mythex اس project کو اپنا Postgres database دیتا ہے۔ کسی مشترکہ database میں ایک table نہیں، کسی دوسرے کے ساتھ ایک schema نہیں: ایک الگ database، جو مانگ پر بنتا ہے اور کوئی استعمال نہ کرے تو سو جاتا ہے۔ ہم نے اسے اس طرح کیوں بنایا، اور اس کی قیمت کیا ہے، یہ یہاں ہے۔

آپ کو کیا ملتا ہے

جب آپ ڈیٹا مانگتے ہیں (“waitlist emails محفوظ کرو”، “bookings محفوظ کرو”) یا /database کمانڈ استعمال کرتے ہیں، تو Mythex:

• project کے لیے ایک مخصوص Postgres database بناتا ہے (فی الحال Postgres 17)،
• connection کی تفصیلات آپ کے workspace اور آپ کی published ایپ میں environment variables کے طور پر ڈالتا ہے، تاکہ وہ کبھی آپ کے کوڈ میں نظر نہ آئیں، اور
• agent کو اجازت دیتا ہے کہ وہ آپ کے لیے tables بنائے اور ڈیٹا پڑھے اور لکھے۔

وہی database live preview اور published ایپ دونوں استعمال کرتے ہیں۔ یہ پانچ منٹ کی بے کاری کے بعد سو جاتا ہے اور اگلی query پر جاگتا ہے۔ نئے databases چھوٹے شروع ہوتے ہیں اور بوجھ میں بڑھ سکتے ہیں، ایک حد کے ساتھ تاکہ بے قابو query کبھی لامحدود نہ بڑھے۔ مزید تفصیلات database docs میں ہیں۔

ایک بڑا مشترکہ database کیوں نہیں؟

ایک مشترکہ database جس میں ایک column ہو کہ ہر row کس ایپ کی ہے، چلانے میں سستا اور انتظام میں سادہ ہے۔ ہم نے چار وجوہات کی بنا پر یہ نہ کرنے کا فیصلہ کیا۔

1. ایسی علیحدگی جس پر بھروسہ نہیں کرنا پڑتا

AI کا لکھا ہوا کوڈ غلطیاں کرتا ہے۔ مشترکہ database میں، کسی ایک ایپ کی query میں ایک بھی غائب WHERE app_id = … کسی دوسرے گاہک کا ڈیٹا پڑھ یا لکھ سکتا ہے۔ ہر ایپ کے اپنے database کے ساتھ، کسی دوسرے گاہک کا ڈیٹا پہنچ میں نہیں ہوتا؛ ایک bug اپنی ہی ایپ کے اندر رہتا ہے۔

2. یہ اصل Postgres ہے، کوئی ملکیتی تہہ نہیں

آپ کی ایپ ایک عام connection string کے ساتھ معیاری Postgres سے بات کرتی ہے۔ جو بھی library، ORM یا tool Postgres کے ساتھ کام کرتا ہے وہ یہاں بھی کام کرتا ہے۔ اگر آپ اپنا project export کر کے اسے کہیں اور چلائیں تو وہ ایک Postgres database کی توقع رکھتا ہے، جو ہر hosting provider دیتا ہے، کسی Mythex کے مخصوص API کی نہیں۔

3. ہر ایپ کو اس کی ضرورت کے مطابق ڈھالا جا سکتا ہے

ایک ایپ کو time slots پر unique constraint والی bookings table چاہیے؛ دوسری کو products پر full-text search چاہیے۔ اپنے database کے ساتھ، ہر ایپ کا schema اور migrations اس کا اپنا معاملہ ہیں۔ کسی چیز کو سب سے کم مشترکہ ڈیزائن میں فٹ ہونے کی ضرورت نہیں۔

4. قیمت استعمال کے ساتھ چلتی ہے

چونکہ ہر database اپنے طور پر سوتا ہے، جو ایپ کوئی استعمال نہیں کرتا اس کی لاگت تقریباً صفر ہے، اور مصروف ایپ کی لاگت اپنی الگ لائن میں نظر آتی ہے۔ Published database کا استعمال اس سے بل ہوتا ہے جو database نے واقعی ناپا ہو، یہ billing کیسے کام کرتی ہے۔

تبادلے

یہ ڈیزائن مفت نہیں ہے:

• Cold starts۔ سوتے ہوئے database کو خاموش وقفے کے بعد پہلی query پر جاگنے میں لمحہ لگتا ہے۔ زیادہ تر ایپس کے لیے یہ شاید ہی محسوس ہو؛ ایسی ایپ کے لیے جسے ہر وقت فوراً جواب دینا ہو، یہ ایک سوچنے کی بات ہے۔
• جاگتے ہوئے بے کار رہنے کی لاگت۔ Database اس وقت تک جاگتا رہتا ہے جب تک کوئی اسے query کرتا رہے۔ جو ایپ اپنے database سے ہر چند سیکنڈ بعد پوچھتی رہے وہ اسے چوبیس گھنٹے جگائے رکھتی ہے اور اس سے زیادہ خرچ کرتی ہے جو مانگ پر query کرے۔ اگر آپ کا استعمال توقع سے زیادہ لگے تو عام طور پر یہی وجہ ہوتی ہے؛ AI سے کہیں کہ polling بند کرے اور ڈیٹا تب لوڈ کرے جب اس کی ضرورت ہو۔
• ہمارے لیے زیادہ چلتے پرزے۔ ہزاروں databases بنانا، ان پر نظر رکھنا اور صاف کرنا ایک سے زیادہ کام ہے۔ یہ بوجھ ہمارا ہے، آپ کا نہیں۔

اگر آپ databases کے لیے نئے ہیں

Database وہ جگہ ہے جہاں ایپ وہ چیز رکھتی ہے جسے اسے یاد رکھنا ہے۔ اگر یہ خیال نیا ہے تو database کیا ہے اور Postgres کیا ہے سے شروع کریں۔ جب آپ ڈیٹا محفوظ کرنے والی کوئی چیز بنانے کے لیے تیار ہوں تو AI کے ساتھ ایپ کیسے بنائیں میں اسے شامل کرنے کا طریقہ ہے۔