یہ سوال تقریباً ہر skeptical ڈیمو میں سامنے آتا ہے جو میں نے دیا ہے۔ کوئی دیکھتا ہے کہ AI بلڈر چند منٹوں میں ایک کام کرنے والی ایپ کھڑی کر دیتا ہے، اور ابتدائی "واہ، یہ تو تیز ہے" کے بعد ان کا پہلا حقیقی سوال کچھ یوں ہوتا ہے: ٹھیک ہے، مگر کیا اس میں واقعی ڈیٹابیس ہے، یا اسے sample ڈیٹا سے fake کیا گیا ہے؟ جائز سوال ہے۔ یہاں وہ سوالات ہیں جو تقریباً اسی ترتیب میں سامنے آتے ہیں جس ترتیب میں کسی شخص کا شک اس چیز کو کھنگالنے کے بعد بڑھتا جاتا ہے۔
کیا واقعی ڈیٹابیس ہے، یا ڈیمو صرف sample ڈیٹا سے fake کیا جا رہا ہے؟
ایک حقیقی ڈیٹابیس موجود ہے۔ جو چیز مختلف ہوتی ہے وہ یہ ہے کہ کون سا، اور یہ فرق سمجھنا ضروری ہے اس سے پہلے کہ آپ کچھ ایسا بنائیں جسے آپ برقرار رکھنا چاہتے ہیں۔ ایک پروٹوٹائپ AI بلڈر جو "نوے سیکنڈز میں یہ کام کرتا دیکھیں" کے لیے optimize کرتا ہے، اکثر SQLite کا انتخاب کرتا ہے — ڈسک پر ایک ہی فائل، صفر سیٹ اپ، ایک یوزر کے لیے حقیقی ایپ چلانے کے قابل۔ ایک بلڈر جو "اسے حقیقی ٹریفک اور کئی tenants سے بچنا ہے" کے لیے optimize کرتا ہے وہ Postgres کا انتخاب کرتا ہے، کیونکہ SQLite کا file-locking ماڈل اس وقت تکلیف دینا شروع کر دیتا ہے جب ایک سے زیادہ process بیک وقت لکھنا چاہیں۔ پوچھیں کہ آپ کون سا حاصل کر رہے ہیں۔ یہ کسی sales page یا support chat سے پوچھنے کے لیے بالکل جائز سوال ہے، اور اگر کوئی اسے واضح طور پر جواب نہ دے سکے، تو یہ خود بھی کچھ بتاتا ہے۔
یہ اصل میں کون سا ڈیٹابیس انجن استعمال کرتا ہے؟
Postgres، ان پلیٹ فارمز میں جو کھلونے سے آگے کسی بھی چیز کے لیے بنائے گئے ہوں۔ یہ بورنگ، درست جواب ہے، اور یہاں بورنگ ہی مطلوب ہے۔ Postgres آپ کو row-level security دیتا ہے تاکہ tenant A کی rows tenant B کے queries کے لیے غیر مرئی رہیں چاہے application کوڈ میں بگ ہی کیوں نہ ہو، حقیقی foreign keys، حقیقی transactions، اور بیس سال کا "کسی نے پہلے ہی یہ edge case حل کر لیا ہے" کا تجربہ۔ دلچسپ ناکامی کا انداز یہ نہیں کہ "کون سا SQL dialect" — بلکہ یہ کہ وہ بلڈرز جو رفتار کے لیے SQLite سے شروع ہوتے ہیں اور استعمال بڑھنے پر کبھی اس سے نکلتے ہی نہیں، کیونکہ live ڈیٹابیس کو یوزرز کے ساتھ migrate کرنا غیر دلچسپ کام ہے جسے ملتوی کرتے رہنا آسان ہوتا ہے۔ اگر آپ کسی ایسی چیز کے لیے بلڈر کا جائزہ لے رہے ہیں جسے آپ برسوں چلانا چاہتے ہیں، تو پوچھیں کہ ایپ ایک یوزر سے آگے بڑھنے پر ڈیٹابیس کا کیا ہوتا ہے۔ ایماندارانہ جواب میں ایک migration path شامل ہوگا؛ ٹال مٹول والا جواب صرف "scalable" لفظ کو بغیر تفصیل کے دہرائے گا۔
کیا میں اپنا ڈیٹا خود دیکھ سکتا ہوں، یا یہ کسی بلیک باکس میں بند ہے؟
آپ کو دیکھ سکنے کے قابل ہونا چاہیے، بس۔ ایک table browser، ایک query console، ایک export بٹن — ایپ کے اپنے UI سے گزرے بغیر rows دیکھنے کا کوئی طریقہ۔ یہ کوئی تکنیکی سوال کم اور اعتماد کا سوال زیادہ ہے۔ ایک AI بلڈر جو ایسا schema بناتا ہے جسے آپ inspect نہیں کر سکتے، وہ آپ سے ایسا کوڈ trust کرنے کا مطالبہ کر رہا ہے جو آپ نے نہ لکھا اور نہ audit کر سکتے ہیں، جو کہ "مجھ پر اعتماد کریں، UI بٹن کام کرتا ہے" سے کہیں بڑی درخواست ہے۔ جو ٹولز یہ صحیح کرتے ہیں وہ underlying ڈیٹا کو ڈیفالٹ کے طور پر آپ کا سمجھتے ہیں، نہ کہ کوئی implementation detail جس سے وہ آپ کو بچا رہے ہیں۔
جب میں کوئی نیا فیچر مانگوں تو کیا یہ schema میں تبدیلی سنبھالتا ہے؟
یہیں یہ واقعی مشکل ہو جاتا ہے، اور یہیں بہت سے AI بلڈرز خاموشی سے ناکام ہو جاتے ہیں۔ ایک column شامل کرنا آسان ہے۔ ایک column شامل کرنا، موجودہ rows کو ایک معقول default سے backfill کرنا، ہر query کو اپ ڈیٹ کرنا جو اس table کو چھوتی ہے، اور یہ سب پہلے سے موجود ڈیٹا کھوئے بغیر کرنا — یہ ایک migration ہے، اور migrations ان چند جگہوں میں سے ایک ہیں جہاں "AI نے ایسا کوڈ لکھا جو compile ہوتا ہے" اس بات کے برابر نہیں کہ "AI نے ایسا کوڈ لکھا جو production ڈیٹا کے خلاف چلانا محفوظ ہے۔" ایک قابل استعمال بلڈر schema میں تبدیلی کو اپنا ایک الگ reviewable قدم سمجھتا ہے، نہ کہ کسی بڑی feature request میں خاموشی سے شامل کوئی چیز۔ اگر آپ "tasks میں due date شامل کریں" مانگیں اور ایسا diff ملے جو صرف frontend کو چھوتا ہو، تو شک کریں — ڈیٹابیس کو یہ پیغام نہیں ملا۔
کیا یہ relationships کو صحیح طریقے سے model کرتا ہے، یا سب کچھ ایک بڑے JSON blob میں flatten ہو جاتا ہے؟
دونوں patterns موجود ہیں، اور آپ کو کون سا ملتا ہے یہ اس سے زیادہ اہم ہے جتنا زیادہ تر لوگ شروع میں سمجھتے ہیں۔ ایک relational schema — users، orders، اور order items کے لیے الگ tables، foreign keys سے جڑی ہوئی — آپ کو ایسے سوالات پوچھنے دیتا ہے جن کا ایپ کے اصل UI نے کبھی تصور بھی نہیں کیا تھا: "کن کسٹمرز نے X اور Y ایک ساتھ خریدے،" "پروڈکٹ کیٹیگری کے حساب سے ہماری refund rate کیا ہے۔" ہر record کے لیے ایک واحد denormalized JSON blob generate کرنا تیز تر ہے اور واقعی سادہ ایپ کے لیے ٹھیک ہے، لیکن یہ ہر مستقبل کی "بس ایک report شامل کر دیں" درخواست کو re-architecture میں بدل دیتا ہے۔ صرف چلتی ایپ نہیں بلکہ schema دیکھنے کو کہیں۔ اگر ہر table مشکوک طور پر `{ id, data jsonb }` جیسی نظر آتی ہے، تو آپ ایسے بلڈر کو دیکھ رہے ہیں جس نے سکرین پر جلدی کچھ دکھانے کو optimize کیا اور اصل ڈیٹا modeling کو ٹال دیا۔
| پیٹرن | یہ کس چیز میں اچھا ہے | یہ کہاں ٹوٹتا ہے |
|---|---|---|
| مناسب relational schema (الگ tables، foreign keys) | Reporting، joins، data integrity، مستقبل کے فیچرز جن کا آپ نے ابھی سوچا بھی نہیں | پہلے سے تھوڑا زیادہ generation وقت؛ ایک سادہ prompt کے لیے پہلی کوشش میں بالکل درست حاصل کرنا مشکل |
| ہر record کے لیے ایک واحد JSON blob | پہلے ڈیمو تک رفتار، سادہ single-entity ایپس (نوٹ لینے کا ٹول، بنیادی فارم) | کوئی بھی query جو records پر پھیلی ہو، کوئی relationship، کوئی report — سب SQL کی بجائے application-code workarounds بن جاتے ہیں |
| Hybrid (core fields columns میں، لچکدار extras jsonb column میں) | ایسی ایپس جن کی core shape مستحکم ہو اور اس کے ساتھ یوزر کے متعین کردہ custom fields ہوں | بلڈر کو یہ جاننے کی ضرورت ہے کہ کب کون سا استعمال کرنا ہے — سست ورژن سب کچھ jsonb column میں ڈال دیتا ہے |
اگر میں اس ڈیٹا کی مقدار سے آگے نکل جاؤں جس کے لیے یہ بنایا گیا تھا تو کیا ہوگا؟
یہ مکمل طور پر اس بات پر منحصر ہے کہ underlying انجن شروع سے concurrency کے لیے بنایا گیا تھا یا نہیں۔ یہ SQLite-بمقابلہ-Postgres سوال ہی ہے، بس مختلف روپ میں۔ SQLite پر چلنے والی ایپ جو ایک یوزر کے لیے چند سو rows سنبھالے، Postgres پر چلنے والی اسی load کی ایپ جیسی محسوس ہوتی ہے — فرق تب ظاہر ہوتا ہے جب آپ concurrent writers، بڑی row تعداد، یا وہ analytical query شامل کریں جسے indexes اور query planning سے فائدہ ہوتا ہے۔ اگر آپ کی ایپ ہمیشہ کے لیے واقعی single-user اور کم volume والی ہے، تو شاید یہ کبھی مسئلہ نہ بنے۔ اگر آپ کچھ ایسا بنا رہے ہیں جس میں آپ کو کسٹمرز کی امید ہے، تو مسئلہ پیدا ہونے سے پہلے scaling کا سوال پوچھیں، support ticket کے سکھانے کے بعد نہیں۔
کیا shared پلیٹ فارم پر میرا ڈیٹا واقعی دوسرے یوزرز سے الگ ہے؟
یہ وہ چیز ہے جس پر میں سب سے زیادہ زور دوں گا، کیونکہ یہ اس وقت تک غیر مرئی رہتی ہے جب تک یہ ناکام نہ ہو۔ Multi-tenant پلیٹ فارمز جو سب کا ڈیٹا ایک ہی ڈیٹابیس میں رکھتے ہیں، انہیں ایک حقیقی isolation boundary چاہیے — row-level security policies جو خود ڈیٹابیس نافذ کرے، نہ صرف application کوڈ جو ہر query میں `WHERE user_id = ?` clause شامل کرنا یاد رکھے۔ فرق اس لیے اہم ہے کیونکہ application-code isolation خاموشی سے ناکام ہوتی ہے: ایک endpoint میں ایک چھوٹا سا رہ جانے والا filter اور tenant A اچانک tenant B کی rows دیکھ سکتا ہے۔ ڈیٹابیس-نافذ isolation بلند آواز سے ناکام ہوتی ہے، کیونکہ query کچھ نہیں لوٹاتی چاہے application کوڈ filter بھول جائے۔ خاص طور پر پوچھیں کہ tenant isolation ڈیٹابیس layer پر نافذ ہے یا application کوڈ پر بھروسہ کیا جاتا ہے۔ زیادہ تر لوگ جو "کیا یہ حقیقی ڈیٹابیس سنبھال سکتا ہے" پوچھتے ہیں، دراصل یہی سوال پوچھ رہے ہوتے ہیں بغیر اس کی اصطلاح جانے۔
کیا میں چاہوں تو سب کچھ export کر کے چھوڑ سکتا ہوں؟
آپ کو اپنے حقیقی ڈیٹا کا مکمل export حاصل کرنے کے قابل ہونا چاہیے — نہ کہ آپ کی ایپ کا اسکرین شاٹ، نہ کسی report کا PDF، بلکہ ایسی شکل میں underlying rows جنہیں آپ کہیں اور load کر سکیں۔ ایک بلڈر جو یہ مشکل بناتا ہے، وہ آپ کو کچھ بتا رہا ہے کہ وہ اس تعلق کو کیسے دیکھتا ہے۔ "AI بلڈر" کا ایماندارانہ مطلب یہ ہے کہ پلیٹ فارم نے آپ کی جانب سے کوڈ اور schema generate کیا؛ اس کا مطلب کبھی یہ نہیں ہونا چاہیے کہ ڈیٹا آپ کا رہنا اسی لمحے بند ہو جائے جب یہ کسی ایسی table میں پہنچے جسے آپ نے خود provision نہیں کیا۔
ڈیٹابیس وہ حصہ ہے جسے کوئی demo نہیں کرتا، اور یہی وجہ ہے کہ کچھ بھی sign up کرنے سے پہلے اس کے بارے میں پوچھنا ضروری ہے۔
اس میں سے کچھ بھی غیرمعمولی انجینئرنگ نہیں ہے۔ یہ وہی due diligence ہے جو آپ کسی بھی backend-as-a-service یا hosting فیصلے پر لاگو کریں گے — AI والا حصہ صرف پوچھنا بھلانا آسان بنا دیتا ہے، کیونکہ ڈیمو plumbing چھپانے میں اتنا اچھا ہوتا ہے۔ پوچھیں کہ کون سا انجن ہے، schema دیکھنے کو کہیں، migrations کے بارے میں پوچھیں، isolation کے بارے میں پوچھیں۔ اگر جوابات مخصوص ہیں، تو آپ غالباً ٹھیک ہیں۔
