কেন প্রতিটি Mythex app নিজের আলাদা database পায়

Mythex-এ আপনি যে app বানান, তাকে যখন ডেটা সংরক্ষণ করতে হয় (সাইন-আপ, বুকিং, অর্ডার), তখন Mythex সেই প্রজেক্টকে নিজস্ব একটি Postgres database দেয়। কোনো shared database-এর একটি table নয়, কারও পাশে একটি schema-ও নয়: একটি আলাদা database, যা চাহিদা অনুযায়ী তৈরি হয় এবং কেউ ব্যবহার না করলে ঘুমায়। কেন আমরা এভাবে বানিয়েছি এবং এর মূল্য কী, তা এখানে।

আপনি কী পান

আপনি যখন ডেটা চান (“waitlist-এর ইমেইল সংরক্ষণ করো”, “বুকিং রাখো”) বা /database কমান্ড ব্যবহার করেন, Mythex:

• প্রজেক্টের জন্য একটি নিবেদিত Postgres database তৈরি করে (বর্তমানে Postgres 17),
• সংযোগের তথ্য environment variable হিসেবে আপনার workspace ও published app-এ ঢোকায়, যাতে সেগুলো কখনও আপনার কোডে না থাকে, এবং
• এজেন্টকে table তৈরি করতে এবং আপনার হয়ে ডেটা পড়তে ও লিখতে দেয়।

Live preview ও published app একই database ব্যবহার করে। এটি ৫ মিনিট অলস থাকলে ঘুমায় এবং পরের query-তে জেগে ওঠে। নতুন database ছোট হয়ে শুরু হয় এবং চাপে পড়লে বড় হতে পারে, একটি সীমার মধ্যে, যাতে একটি বেপরোয়া query অসীম বড় হয়ে না যায়। আরও জানতে database docs দেখুন।

একটি বড় shared database নয় কেন?

একটি shared database-এ একটি column থাকে, যেটি বলে কোন row কোন app-এর। এটি চালাতে সস্তা এবং পরিচালনা সহজ। আমরা চারটি কারণে এটি না করার সিদ্ধান্ত নিয়েছি।

১. এমন বিচ্ছিন্নতা, যা আপনাকে বিশ্বাস করতে হয় না

AI-লেখা কোড ভুল করে। একটি shared database-এ একটি app-এর query থেকে একটি WHERE app_id = … বাদ পড়লে, সে অন্য গ্রাহকের ডেটা পড়তে বা লিখে বদলে দিতে পারে। প্রতি app-এর আলাদা database থাকলে, অন্য কোনো গ্রাহকের ডেটা নাগালের মধ্যেই আসে না, একটি bug তার নিজের app-এর মধ্যেই থাকে।

২. এটি একটি আসল Postgres, কোনো মালিকানা স্তর নয়

আপনার app একটি স্বাভাবিক connection string দিয়ে সাধারণ Postgres-এর সঙ্গে কথা বলে। Postgres-এর সঙ্গে কাজ করে এমন যেকোনো library, ORM বা tool এখানেও কাজ করে। আপনি যদি অন্য কোথাও চালাতে আপনার প্রজেক্ট export করেন, সেটি একটি Postgres database আশা করে, যা প্রতিটি hosting provider দেয়, Mythex-নির্দিষ্ট কোনো API নয়।

৩. প্রতিটি app নিজের প্রয়োজন অনুযায়ী গঠিত হতে পারে

এক app চায় bookings table-এ time slot-এর উপর একটি unique constraint, আরেক app চায় পণ্যের উপর full-text search। নিজস্ব database থাকলে প্রতিটি app-এর schema ও migration তার নিজের ব্যাপার। কিছুই সর্বনিম্ন সাধারণ নকশায় মানাতে হয় না।

৪. খরচ ব্যবহারের সঙ্গে চলে

প্রতিটি database নিজে নিজে ঘুমায় বলে, কেউ ব্যবহার না করা app-এর খরচ প্রায় শূন্য, আর একটি ব্যস্ত app-এর খরচ তার নিজের আলাদা লাইনে দেখা যায়। Published database-এর ব্যবহার সেই পরিমাপ থেকে বিল হয় যা database আসলে মেপেছে, এই billing কীভাবে কাজ করে।

এর ট্রেড-অফ

এই নকশা বিনামূল্যে নয়:

• Cold start। একটি ঘুমন্ত database শান্ত সময়ের পর প্রথম query-তে জেগে উঠতে একটু সময় নেয়। বেশির ভাগ app-এর জন্য এটি প্রায় চোখে পড়ে না; যে app-কে যেকোনো সময় তাৎক্ষণিক উত্তর দিতে হয়, তার জন্য এটি বিবেচনার বিষয়।
• জেগে থাকার খরচ। কিছু query করতে থাকলে database জেগে থাকে। যে app প্রতি কয়েক সেকেন্ডে database-কে poll করে, সে database-কে সারাক্ষণ জাগিয়ে রাখে এবং যে app চাহিদা অনুযায়ী query করে তার চেয়ে বেশি খরচ হয়। আপনার ব্যবহার প্রত্যাশার চেয়ে বেশি মনে হলে, সাধারণত এটিই কারণ। তখন এজেন্টকে বলুন polling বন্ধ করতে এবং দরকার হলে তবেই ডেটা লোড করতে।
• আমাদের জন্য আরও চলমান অংশ। হাজার হাজার database তৈরি, ট্র্যাক ও পরিষ্কার করা একটির চেয়ে বেশি কাজ। সেই বোঝা বহন করা আমাদের কাজ, আপনার নয়।

ডেটাবেস নতুন হলে

Database হলো সেই জায়গা, যেখানে একটি app যা মনে রাখতে হয় তা রাখে। ধারণাটি নতুন হলে database কী এবং Postgres কী দিয়ে শুরু করুন। ডেটা সংরক্ষণ করে এমন কিছু বানাতে প্রস্তুত হলে, AI দিয়ে app বানানোর উপায় যোগ করার ধাপগুলো বলে দেয়।