المشكلة
قواعد البيانات اللي بتتعمل بسرعة في بداية المشروع غالبًا بتُترك بإعدادات افتراضية غير آمنة — وصول مفتوح للجميع (`0.0.0.0/0`)، بدون نسخ احتياطي، وبدون Indexes تحسّن الأداء.
الحل
نجهّز القاعدة، المستخدمين، والصلاحيات بشكل مقيّد وصحيح من البداية، مع Indexes أساسية للأداء ونسخ احتياطي دوري.
ماذا نقدّم
- إنشاء قاعدة البيانات والمستخدمين (Users)
- إعداد الـ Collections الأساسية
- Indexes أساسية لتحسين الأداء
- ضبط التحكم في الوصول (Access Control) بشكل مقيّد وليس مفتوحًا
- ربط الاتصال (Connection) بتطبيقك
- مراقبة أساسية ونسخ احتياطي دوري
- مساعدة في نقل بيانات موجودة (Migration) إن لزم
ماذا نحتاج منك
- وصف مبسّط لهيكل البيانات المتوقع (المستخدمين، الطلبات، المنتجات، إلخ)
- بيانات موجودة بالفعل تحتاج نقلًا، إن وُجدت
ممارسات الأمان التي نلتزم بها
- عدم استخدام `0.0.0.0/0` (فتح الوصول لأي عنوان) كإعداد افتراضي
- عدم مشاركة كلمة المرور أو Connection String بطريقة غير آمنة
- صلاحيات مقيّدة حسب الحاجة الفعلية لكل مستخدم/خدمة
السعر
سعر ثابت
Setup (لمرة واحدة)
500 ج.م
إنشاء القاعدة، المستخدمين، الصلاحيات، والـ Indexes الأساسية.
إدارة شهرية
600 ج.م/شهريًا
مراقبة أساسية ونسخ احتياطي دوري.
إدارة سنوية
3,200 ج.م/سنويًا
نفس نطاق الإدارة الشهرية بسعر سنوي مجمّع.
متى تكون هذه الخدمة مناسبة؟
- بياناتك مرنة وغير جدولية (مستندات JSON متغيرة الحقول).
- محتاج قاعدة بيانات مستقلة بجانب تطبيق موجود بالفعل.
متى لا تناسبك
- لو بياناتك علائقية بجداول وعلاقات واضحة — راجع PostgreSQL.
الأسئلة الشائعة
هل تفتحون الوصول للجميع (0.0.0.0/0) عشان يسهل الاتصال؟
لا. هذا إعداد غير آمن ولا نستخدمه كإعداد افتراضي. الوصول يُقيَّد لعناوين أو خدمات محددة حسب حاجة تطبيقك فعليًا.
هل تشاركون Password أو Connection String بشكل غير آمن؟
لا. بيانات الاتصال الحساسة تُسلَّم لك عبر قناة آمنة متفق عليها، وليس عبر البريد أو الرسائل بشكل مكشوف كإجراء افتراضي.
هل النسخ الاحتياطي جزء من الخدمة؟
نعم، النسخ الاحتياطي الأساسي جزء من الإعداد والإدارة الشهرية.