بدائل Supabase في 2026: أي منصة تناسب تطبيقك؟

تختلف أفضل بدائل Supabase بحسب الجزء الذي تريد استبداله في المنصة: Appwrite لخلفية برمجية متكاملة مع خيار الاستضافة الذاتية، وNeon للانتقال مع إبقاء Postgres أساسًا للتطبيق، وFirebase لتطبيق جوّال يعتمد على بيانات المستندات المتزامنة لحظيًا. تستبدل هذه الخيارات السبعة أجزاء مختلفة من المنظومة؛ أما إذا كانت قاعدة بيانات Supabase ونظام تسجيل الدخول وقواعد الوصول تلائم تطبيقك بالفعل، فقد يكون البقاء هو القرار الأنسب.

جرى التحقق بالرجوع إلى صفحات الأسعار ووثائق الجهات المطوّرة في 14 نوفمبر 2026. تستند هذه المقارنة إلى الوثائق، وليست اختبارًا عمليًا أو ترتيبًا للأداء.

بدائل Supabase في لمحة

حدّد أولًا ما الذي ستستبدله، ثم قارن الفاتورة. تستطيع قاعدة بيانات مُدارة استبدال المكان الذي تُحفظ فيه جداولك؛ أما منصة الخلفية البرمجية فتوفّر أيضًا الخدمات التي يستدعيها تطبيقك لتسجيل دخول المستخدمين وتخزين الملفات وتنفيذ الشيفرة على الخادم.

وحدة CU-hour هي مقياس Neon لحوسبة قاعدة البيانات، وسعرها لا يمثل فاتورة شهرية كاملة. كذلك لا تبيع Firebase وAmplify اشتراكًا واحدًا يغطي جميع موارد الخلفية. وتستند العروض المبدئية هنا إلى صفحات الأسعار المرتبطة في كل قسم.

ما الذي يستبدله كل خيار؟

جُمعت بعض الخصائص في خلايا مشتركة لتسهيل قراءة المقارنة كاملة. يُقصد بـ«التخزين» تخزين الملفات أو الكائنات، لا مساحة قاعدة البيانات. وتعني «الاستضافة الذاتية» تشغيل الخلفية بنفسك، لا مجرد نشر الواجهة الأمامية في مكان آخر.

قد يكون Neon العنصر المفاجئ في الجدول. فالمنتج الحالي يشمل المصادقة وتخزين الكائنات والدوال، مع تحديث لحظي في المرحلة التجريبية. وصفه بأنه «مجرد قاعدة بيانات بلا مصادقة أو تخزين» لم يعد يعكس ما يمكن شراؤه اليوم.

حدّد شكل الخلفية البرمجية أولًا

احتفظ بـ Postgres إذا كانت قيمة تطبيقك قائمة بالفعل على SQL. PostgreSQL، التي تُختصر عادة إلى Postgres، هي قاعدة البيانات العلائقية وراء Supabase: تحفظ السجلات المترابطة في جداول وتتيح الاستعلام عبرها. إذا كانت بيانات العملاء والفواتير والصلاحيات تعمل فيها كما ينبغي، فإن الحفاظ على هذا النموذج يجنبك إعادة كتابة غير ضرورية.

لذلك يُفضّل لمؤسس ينقل تطبيق فواتير أن يقيّم أولًا خيارًا يحافظ على Postgres، قبل تبنّي قاعدة مستندات جديدة. السؤال المهم هو: هل تستطيع الوجهة تنفيذ الاستعلامات وقواعد الوصول التي يعتمد عليها العمل؟ وليس: هل تبدو لوحة التحكم أبسط؟

استبدل الخلفية كاملة عندما تكون المشكلة في الخدمات المتكاملة. إذا كنت تحتاج إلى نظام مختلف لتسجيل الدخول وواجهة ملفات وبيئة تشغيل للدوال ونموذج تشغيل آخر، فقيّم الحزمة كوحدة متكاملة. يستحق Appwrite وNhost النظر هنا، كما ينبغي إدراج خدمات Neon الموسّعة في التقييم.

لا تغيّر نموذج البيانات إلا لفائدة واضحة في التطبيق. مزامنة المستندات في Firebase، ونموذج البرمجة التفاعلي في Convex، وخفة الخلفية ذاتية الاستضافة في PocketBase، كلها أسباب تستحق التفكير في إعادة الكتابة. أما الانزعاج من الفاتورة دون معرفة المورد الذي تسبب فيها، فليس سببًا كافيًا.

إذا كانت أدوار الخدمات لا تزال متداخلة لديك، يشرح دليل بنية Supabase الجزء المسؤول عن البيانات والهوية والملفات ومنطق التطبيق.

سبعة بدائل وما يتطلبه الانتقال إلى كل منها

1. Appwrite: الخيار الأبرز لخلفية متكاملة

يستبدل Appwrite حزمة خدمات Supabase الواسعة: المصادقة وقواعد البيانات وتخزين الملفات والدوال والتحديثات اللحظية. وهو أول خيار يستحق التقييم إذا أردت جمع هذه الخدمات معًا، مع اختيار فعلي بين السحابة المُدارة وبنيتك التحتية الخاصة.

بالنسبة إلى مؤسس يبني بوابة عملاء، تبدو الفائدة واضحة: يمكن جمع تسجيل الدخول وسجلات العملاء والمستندات المرفوعة والإجراءات المنفذة على الخادم في منصة واحدة. وهذا أقرب إلى ما تشتريه من Supabase من مجرد حساب لاستضافة قاعدة بيانات.

لكن خيارات قواعد البيانات تحتاج إلى تدقيق. يستخدم العرض الحالي TablesDB بوصفه الخيار الافتراضي دون خوادم، ويعرض خيارات مخصصة تشمل PostgreSQL وMySQL وقواعد المستندات. لا تفترض أن اختيار PostgreSQL يجعل استدعاءات عميل Supabase أو صلاحيات التخزين أو تكامل المصادقة قابلة للنقل تلقائيًا. فتوافق محرك قاعدة البيانات وتوافق واجهات API للتطبيق فحصان منفصلان.

Appwrite مفتوح المصدر ويدعم الاستضافة الذاتية عبر Docker أو Kubernetes. ويوضح دليل الاستضافة الذاتية مسؤولية التشغيل: أنت من يتولى الصيانة والتوسع. لهذا الخيار قيمة عندما تكون السيطرة أولوية، لكنه لا يضمن أن تشغيله بنفسك أقل تكلفة.

سبب قد يدفعك إلى تركه: تريد العمل مباشرة ضمن بنية Postgres الحالية، بينما يضيف تكييف التطبيق مع واجهات خدمات Appwrite عملًا يفوق ما يوفّره. وفي خطة Free السحابية، يؤدي بلوغ حدود الموارد إلى تجميد المشروع؛ فلا ينبغي اعتماد مخصصات نموذج أولي للإنتاج دون مراجعة.

الأنسب لـ: مؤسس يريد حزمة خلفية واسعة مع مسار للاستضافة الذاتية.
أبرز ما يميّزه: تنوّع الخدمات في النشر المُدار والتشغيل الذاتي.
الأسعار: Pro من $25/شهر، بحسب صفحة أسعار Appwrite.
التجربة المجانية: تتوفر خطة Free سحابية؛ وليست مجرد تجربة محددة المدة.

كيف تقيّم Appwrite قبل الانتقال؟

1. 1

   اختر مسار استخدام يمثّل التطبيق

   اختبر عميلًا يسجل دخوله ويقرأ سجله الخاص ويرفع مستندًا خاصًا. فهذا يختبر أجزاء من الخلفية أكثر مما تختبره قائمة مهام عامة.

2. 2

   احصر كل اعتماد

   دوّن استعلام قاعدة البيانات والتحقق من الهوية وصلاحية التخزين والإجراء على الخادم التي يستخدمها هذا المسار. وحدّد خدمة Appwrite التي ستحل محل كل منها.

3. 3

   ابنِ نموذج تحقق معزولًا

   استخدم نسخًا من سجلات غير حساسة وحسابًا اختباريًا. تحقّق من أن الحساب يستطيع الوصول إلى مستنده، ولا يستطيع الوصول إلى مستند عميل آخر.

4. 4

   حدّد من سيتولى التشغيل

   لا تختر السحابة أو الاستضافة الذاتية قبل إسناد مسؤولية النسخ الاحتياطي والترقيات والاستجابة للحوادث. ثم قرّر إن كان الانتقال يحل المشكلة الأصلية.

2. Neon: أولوية لـ Postgres مع خدمات خلفية أوسع الآن

يُعد Neon أقوى نقطة بداية هنا إذا أردت الاحتفاظ بـ Postgres وإعادة النظر في الخدمات المحيطة بها. تتيح ميزة تفريع قاعدة البيانات إنشاء بيئات مستقلة، وهي مفيدة عندما يحتاج المطوّر إلى تجربة تعديل على المخطط دون تحويل بيئة الإنتاج إلى ساحة تجارب.

خذ تطبيق SaaS يتولى خادمه بالفعل منطق الأعمال. قد يحتاج إلى مضيف مختلف لقاعدة البيانات، دون استبدال مزوّد تسجيل الدخول أو خدمة الملفات في الوقت نفسه. إبقاء نطاق الانتقال محدودًا يجعل المشروع أسهل في الفهم والإدارة.

لكن Neon أصبح قادرًا على أداء دور أوسع. يوثّق تحديث منتج الخلفية خدمات Managed Better Auth والدوال وتخزين الكائنات المتوافق مع S3؛ ويمكن تفريع هذه الخدمات مع قاعدة البيانات. التحديث اللحظي حاليًا في المرحلة التجريبية. وإذا كان منتجك يعتمد على التعاون المباشر، فقيّم هذه الحالة قبل اتخاذها سببًا للانتقال.

تتوفر نواة قاعدة البيانات في مستودع الجهة المطوّرة المفتوح المصدر. لكن هذا يختلف عن الحصول على بديل جاهز للاستضافة الذاتية يكافئ الخلفية المستضافة كاملة. اختر Neon من أجل خدمته المُدارة؛ ولا تعتبر إتاحة المستودع خطة خروج سهلة لكل ميزة.

سبب قد يدفعك إلى تركه: يعتمد تطبيقك على سلوك خدمات مترابط بإحكام ما زال يحتاج إلى تكييف، أو تحتاج إلى بديل ناضج لمسار لحظي لا يزال تجريبيًا. الاحتفاظ بـ SQL يقلّل إعادة كتابة قاعدة البيانات، لكنه لا يلغي ترحيل الخدمات.

الأنسب لـ: تطبيقات Postgres القائمة والمطوّرين الذين يريدون بيئات قواعد بيانات معزولة.
أبرز ما يميّزه: تفريع يتجاوز الجداول الآن ليشمل خدمات الخلفية المرتبطة بها.
الأسعار: Launch بحسب الاستخدام، بسعر حوسبة $0.106 لكل CU-hour مع رسوم للموارد الأخرى؛ راجع صفحة أسعار Neon.
التجربة المجانية: تتوفر خطة Free.

3. Firebase: اختره لمسار عمل الجوّال القائم على المستندات

يناسب Firebase تطبيقًا تعتمد تجربته الأساسية على البيانات اللحظية والعمل دون اتصال، خصوصًا على الجوّال. تحفظ قاعدة Cloud Firestore المستندات داخل مجموعات، وتدعم مستمعي التحديثات اللحظية والعمل دون اتصال، كما تشرح وثائق Firestore.

تخيّل تطبيق خدمات ميدانية يحدّث فيه الموظفون سجلات المهام بينما يتقطع الاتصال. هذا سبب ملموس لفحص سلوك عميل Firestore. أما نقل قاعدة فواتير مستقرة لمجرد أن المنصتين توفّران زر تسجيل دخول، فمبرره أضعف.

يمكن لـ Firebase استبدال أدوار الخلفية الرئيسية عبر Authentication وFirestore وCloud Storage وCloud Functions. لكنه خلفية مُدارة مملوكة، وليس منظومة إنتاج يمكنك نقلها إلى خادمك. كما أن مسار Firestore القياسي يغيّر طريقة تنظيم البيانات والاستعلام عنها.

وهنا تفصيل مهم: يعرض Firebase الآن SQL Connect المدعوم بـ Cloud SQL for PostgreSQL. لذلك لم تعد عبارة «لا يوفّر Firebase خيار SQL» دقيقة على إطلاقها. قيّم هذا الخيار كبنية مستقلة، بدل افتراض أن خصائص مستندات Firestore وSQL Connect قابلة للتبادل.

سبب قد يدفعك إلى تركه: تتجاوز احتياجات الاستعلام العلائقي نموذج المستندات الذي اخترته، أو تريد استضافة مستقلة وعلاقة أبسط بين الاستخدام والتكلفة. الانتقال من Supabase إلى Firestore يعني إعادة صياغة الاستعلامات وقواعد الوصول، لا استعادة نسخة تفريغ Postgres.

الأنسب لـ: تطبيقات الجوّال والويب التي تستفيد من سلوك مستندات Firestore اللحظي ودون اتصال.
أبرز ما يميّزه: مزامنة المستندات مع تطبيق العميل.
الأسعار: Blaze بالدفع بحسب الاستخدام، دون اشتراك شهري ثابت موحّد في صفحة أسعار Firebase.
التجربة المجانية: Spark خطة بلا تكلفة، لكن جدول الخدمات الحالي يشترط Blaze لاستخدام Cloud Storage وCloud Functions.

للتعمّق في الاختيار بين هاتين البنيتين، اقرأ مقارنة Supabase وFirebase.

4. Nhost: احتفظ بـ Postgres واختر GraphQL عن قصد

يكون Nhost الأقرب لاحتياجك إذا أردت خلفية Postgres تتمحور واجهتها حول GraphQL، وهي لغة استعلام تتيح للعميل طلب حقول وسجلات مترابطة بعينها. تجمع المنظومة Postgres وواجهة GraphQL من Hasura والمصادقة والتخزين والدوال دون خوادم.

في بوابة عملاء تعرض الحساب ومشاريعه وأحدث أنشطتها معًا، قد يناسب هذا الشكل من الواجهات الواجهة الأمامية جيدًا. سبب الانتقال هنا هو تفضيل واجهة التطبيق تلك، لا افتراض أن جميع منصات Postgres تتصرف بالطريقة نفسها.

يصف مستودع Nhost منظومة مفتوحة المصدر ومثالًا للاستضافة الذاتية باستخدام Docker Compose. ويوثّق أيضًا تطويرًا محليًا يتتبّع ترحيلات قاعدة البيانات وبيانات Hasura الوصفية. وهذه البيانات مهمة: فإعداد واجهة API وصلاحياتها جزء من التطبيق، إلى جانب مخطط قاعدة البيانات.

سبب قد يدفعك إلى تركه: لا تريد صيانة طبقة إعداد GraphQL وHasura. إذا كان خادمك يقدّم بالفعل نقاط النهاية التي يحتاجها المنتج، فقد تضيف طبقة API جديدة مسؤولية أخرى دون حل مشكلة للعميل.

يوفّر الاحتفاظ بـ Postgres وجهة مألوفة للبيانات. لكنه لا يترجم تلقائيًا سياسات الصفوف في Supabase إلى تفويض واجهة Nhost القائم على الأدوار. تعامل مع هذين الأمرين كمعيارَي قبول منفصلين.

الأنسب لـ: فرق تريد تحديدًا Postgres مع خلفية تعطي الأولوية لـ GraphQL.
أبرز ما يميّزه: اشتراكات GraphQL والهوية وتخزين الملفات متكاملة حول Postgres.
الأسعار: Pro من $25/شهر، مع خطط على مستوى المؤسسة في صفحة أسعار Nhost.
التجربة المجانية: Starter مجانية؛ وتتوقف المشاريع غير النشطة مؤقتًا.

5. Convex: اختر نموذج البرمجة التفاعلي

يستبدل Convex الوصول إلى قاعدة البيانات ومنطق التطبيق على الخادم بخلفية تفاعلية يعمل معها التطبيق عبر دوال JavaScript أو TypeScript. ويقدّم أيضًا المصادقة وتخزين الملفات والمهام المجدولة.

تطبيق التخطيط التعاوني مرشح مناسب: يحدّث عدة أشخاص عملًا مشتركًا، وتحتاج الواجهة إلى عكس الحالة المتغيّرة. اختر Convex لأنك تريد التطوير حول هذا السلوك، لا لأنك تتوقع نقل تطبيق SQL قائم دون تعديل.

توضح وثائق قاعدة البيانات فرقًا مفيدًا: يخزّن Convex مستندات شبيهة بـ JSON ويدعم النمذجة العلائقية. هو ليس Postgres، لكن وصفه بأنه لا يدعم العلاقات خطأ أيضًا. تتم القراءة والكتابة عبر واجهة الدوال بدلًا من SQL.

الاستضافة الذاتية مدعومة. وتشرح وثائق ترخيص الخلفية ترخيص fair-source بقيود على الخدمات المستضافة المنافسة، مع انتقال مستقبلي إلى ترخيص Apache. وهذا يحتاج إلى وصف أدق من وضع علامة «مفتوح المصدر» دون قيد.

سبب قد يدفعك إلى تركه: يصبح توافق SQL وأدوات Postgres المحيطة بها أهم من نموذج التطبيق التفاعلي. تستطيع الاستضافة الذاتية تغيير مكان تشغيل Convex، لكنها لا تحوّل استعلاماته إلى SQL.

الأنسب لـ: مطوّرين يختارون خلفية تفاعلية لتطبيق جديد أو لتطبيق يعيدون كتابته عن قصد.
أبرز ما يميّزه: دوال البيانات وسلوك التطبيق التفاعلي ضمن نموذج برمجة واحد.
الأسعار: تبدأ Starter من $0/شهر إضافة إلى الاستخدام، بحسب صفحة أسعار Convex.
التجربة المجانية: تتوفر خطة Free.

6. PocketBase: صغير وذاتي الاستضافة، مع تحفّظ واضح للإنتاج

يجمع PocketBase قاعدة بيانات ومصادقة واشتراكات لحظية وتخزين ملفات وواجهة إدارة في خلفية صغيرة ذاتية الاستضافة. وتجعل قاعدة SQLite المضمّنة عرضه مختلفًا عن كل من Postgres المُدارة ومجموعة الخدمات السحابية.

لسجل معدات داخلي أو أداة مجتمعية محدودة، قد يكون تشغيل الخلفية من ملف تنفيذي واحد نموذجًا جذابًا. لكنك لا تزال بحاجة إلى شخص ينشرها وينسخها احتياطيًا ويراقبها ويتولى ترقياتها. «ملف واحد» يصف طريقة تجميع البرنامج، ولا يعني اختفاء أعمال التشغيل.

تذكر مقدمة الجهة المطوّرة أن PocketBase لا يزال قيد التطوير النشط، ولا يضمن بعدُ التوافق الكامل مع الإصدارات السابقة، ولا يُنصح به للتطبيقات الإنتاجية الحرجة إلا إذا كنت تقبل أعمال الترحيل اليدوية. هذا التحذير أهم من مقارنة افتراضية لقابلية التوسع.

PocketBase مفتوح المصدر وذاتي الاستضافة. يستبدل عدة قدرات في الخلفية يتعامل معها المستخدم، لكنه ليس خطة استضافة مُدارة ولا وجهة مباشرة لاستعادة نسخة Postgres من Supabase. فنموذج بيانات SQLite وواجهة التطبيق يحتاجان إلى أعمال ترحيل خاصة بهما.

سبب قد يدفعك إلى تركه: يصبح التطبيق حرجًا لدرجة تستدعي ضمانات تشغيلية أقوى مما تستطيع توفيره، أو لا تعود مسؤولية الترقيات مناسبة للمشروع.

الأنسب لـ: تطبيقات صغيرة يقبل مالكها عن قصد صيانة الاستضافة الذاتية.
أبرز ما يميّزه: قاعدة بيانات ومصادقة وملفات وتحديث لحظي في تطبيق مستقل مدمج.
الأسعار: تعرض الجهة المطوّرة برنامجًا مجانيًا دون خطة استضافة مدفوعة؛ والبنية التحتية منفصلة.
التجربة المجانية: لا تحتاج إلى تجربة مستضافة لاستخدام البرنامج.

7. AWS Amplify: الأنسب عندما تكون AWS بيئة التشغيل الحالية

يناسب AWS Amplify فريقًا يريد بناء خلفية تطبيقه على خدمات AWS، ويقبل إدارة الحدود الفاصلة بينها. يستخدم مسار البيانات القياسي Amazon DynamoDB مع واجهة AWS AppSync واشتراكات لحظية.

بالنسبة إلى شركة تعمل بالفعل داخل حساب AWS، قد يكون هذا خيارًا عمليًا: تستخدم الهوية Amazon Cognito، والملفات Amazon S3، ويمكن أن يستخدم منطق الخلفية المخصص AWS Lambda. أما لمؤسس منفرد يختار خلفيته الأولى، فهذه الحدود نفسها تعني مفاهيم إضافية يجب فهمها عند حدوث عطل.

يوضح دليل إعداد البيانات في Amplify كيف تُنشئ تعريفات النماذج في TypeScript موارد قاعدة البيانات وواجهة API. هذا تمهيد برمجي منتج، لكن ترحيل Supabase لا يزال يتطلب مواءمة بيانات SQL والصلاحيات والدوال مع خدمات AWS المختارة.

مكتبات JavaScript مفتوحة المصدر. أما خدمات AWS المُدارة التي تتصل بها فليست خلفية محمولة للاستضافة الذاتية. نشر الموارد داخل حسابك في AWS يمنحك ملكية إعدادات السحابة تلك، لا الاستقلال عن AWS.

سبب قد يدفعك إلى تركه: تكون احتياجات التطبيق بسيطة بما يكفي لجعل تنسيق خدمات AWS أكثر عبئًا تشغيليًا من حزمة خلفية أشد تكاملًا.

الأنسب لـ: فرق مجهّزة بالفعل لتشغيل التطبيقات على AWS.
أبرز ما يميّزه: مسار تحدّده الشيفرة إلى خدمات AWS للهوية والبيانات والتخزين والدوال.
الأسعار: لا حد أدنى شهري لاستخدام الخلفية؛ وتُحاسب الخدمات الأساسية بحسب الاستخدام، وفق صفحة أسعار Amplify.
التجربة المجانية: يتوقف توفر AWS Free Tier على أهلية الخدمة والحساب.

عند بدء تقييم جديد، ارجع إلى وثائق Amplify الحالية، وتحقّق من أن أي شرح تتبعه يصف الإعداد نفسه.

أي بديل لـ Supabase تختار؟

اختر Appwrite عندما تحتاج إلى حزمة الخلفية كاملة. يتصدر القائمة لهذه المهمة تحديدًا لأنه يجمع اتساع الخدمات مع مسار واضح للاستضافة الذاتية. وتنتقل التوصية إلى Nhost عندما يكون الاحتفاظ بـ Postgres وتبنّي GraphQL أهم.

اختر Neon عندما يكون الحفاظ على Postgres القيد الأول. ابدأ بترحيل قاعدة البيانات، ثم حدّد الخدمات الإضافية التي تريدها منه. لا تحوّل انتقالًا محدودًا لقاعدة البيانات إلى إعادة بناء للهوية لمجرد أن الخدمتين متاحتان من المزوّد نفسه.

اختر Firebase أو Convex إذا كان سلوك التطبيق يستحق إعادة الكتابة. يناسب مسار Firestore في Firebase المستندات اللحظية والعملاء الذين يعملون دون اتصال؛ ويناسب Convex نموذج دوال البيانات التفاعلي. وفي الحالتين، إثبات نجاح أصعب مسار استخدام أهم من نقل أسهل جدول.

اختر PocketBase لبساطة مقصودة، أو Amplify لالتزام قائم بـ AWS. لا يُعد أي منهما بديلًا عامًا لكل الحالات. ينقل PocketBase المسؤولية إلى المشغّل، بينما يوزّعها Amplify على خدمات AWS.

إذا تجاوزت احتياجات البحث المتجهي pgvector، فقيّم Pinecone كطبقة استرجاع منفصلة، لا بديلًا لخلفية Supabase.

متى يكون البقاء على Supabase هو القرار الصحيح؟

ابقَ عندما يكون نموذج SQL وتدفق تسجيل الدخول وأمان مستوى الصف ملائمة للمنتج بالفعل، وحين لا يفعل البديل المقترح سوى إعادة إنتاجها دون فائدة ملموسة. أمان مستوى الصف، أو RLS، هو نظام قواعد في قاعدة البيانات يمكنه قصر ما يراه كل عميل على سجلاته وحدها.

بوابة العملاء التي تعمل جيدًا لا تتحسن لمجرد نقل سجلاتها إلى لوحة تحكم مختلفة. ينبغي أن يحل الانتقال المجدي مشكلة تستطيع تسميتها: سلوكًا مطلوبًا في تطبيق العميل، أو متطلبًا تشغيليًا، أو قيدًا في خدمة، أو مشكلة تكلفة موثّقة.

أسعار Supabase

حدّد أولًا إن كان مصدر القلق هو الخطة أو الحوسبة أو الملفات أو نقل البيانات أو موردًا آخر. يقدّم شرح أسعار Supabase نقاش الشراء الكامل. قارن الخدمات التي سيظل التطبيق يحتاج إليها بعد الانتقال، بما فيها الخدمات التي لن يشملها ترحيل قاعدة البيانات وحدها.

أسعار التخزين في Supabase

إذا كانت الملفات المرفوعة هي المشكلة، فقد لا يغيّر تبديل محرك قاعدة البيانات شيئًا فيها. راجع ما تخزّنه وكيف ينزّله المستخدمون قبل اختيار خلفية جديدة بالكامل. وتعامل مع أي تغيير يقتصر على التخزين كمشروع مستقل، يشمل نطاقه قواعد الوصول إلى الملفات وروابطها في التطبيق.

ما الذي يمكن نقله من Supabase وما الذي يحتاج إلى إعادة بناء؟

بيانات Postgres هي الجزء القابل للنقل؛ أما التطبيق العامل فيشمل أكثر بكثير من الصفوف. توثّق Supabase النسخ الاحتياطي المنطقي واستعادة الأدوار والمخطط والبيانات، ثم تتناول كائنات التخزين وEdge Functions كأعمال ترحيل منفصلة في دليل النسخ الاحتياطي والاستعادة.

إذا كانت الوجهة الأخرى Postgres، فهذا يجعل قاعدة البيانات نقطة بداية معقولة. تحقّق من الإضافات والإصدارات المدعومة واعتمادات التطبيق الخاصة قبل افتراض أن الاستعادة كافية. أما مع Firestore أو Convex أو SQLite، فتوقّع تحويلًا للبيانات وإعادة كتابة للاستعلامات.

المصادقة تحتاج إلى خطة للهوية. يذكر دليل الاستعادة إلى استضافة ذاتية في Supabase إمكان تضمين سجلات المستخدمين في نسخة تفريغ قاعدة البيانات، بينما تحتاج أسرار JWT وإعدادات المزوّد وروابط إعادة التوجيه إلى إعداد منفصل. وفي الانتقال الموثّق إلى نسخة جديدة ذاتية الاستضافة، تصبح الرموز الحالية غير صالحة ويجب أن يسجّل المستخدمون دخولهم مجددًا.

هذا الدليل يخص الاستعادة من Supabase إلى Supabase. ولا يَعِد بأن مزوّدًا مختلفًا يستطيع استيراد كل حساب أو الحفاظ على كل جلسة. عند الانتقال بين المزوّدين، حدّد كيفية مطابقة الحسابات ومعرّفات الهوية وطرق تسجيل الدخول قبل جدولة التحويل الفعلي.

يمكن تصدير RLS، لكن معناها يعتمد على نظام الهوية المحيط بها. السياسات كائنات Postgres، وليست شيفرة غير قابلة للنقل بطبيعتها. لكن وثائق RLS في Supabase تتضمن دوال مساعدة مثل auth.uid() وauth.jwt(). يجب أن توفّر الوجهة سياق الهوية المناسب، وإلا فعليك تكييف السياسات. نجاح استيراد SQL لا يثبت استمرار عزل بيانات العملاء.

تحتاج Edge Functions إلى فحص بيئة التشغيل والتكاملات. تصفها Supabase بأنها دوال TypeScript قابلة للنقل تعمل على بيئة متوافقة مع Deno في دليل Edge Functions. يتركز عمل الترحيل في النشر والأسرار ومصادقة البوابة والاستدعاءات العائدة إلى خدمات Supabase. وقد يتطلب الانتقال إلى بيئة تشغيل غير متوافقة تعديلات في الشيفرة أيضًا.

قبل نقل الإنتاج، أثبت نجاح المسار كاملًا في بيئة معزولة: تسجيل الدخول وقراءة السجلات المسموح بها ورفض الوصول المحظور ورفع ملف خاص واسترجاعه وتنفيذ إجراء الأعمال المهم. احتفظ بمسار للرجوع حتى تعمل هذه السلوكيات في الوجهة.

كيف اختيرت هذه البدائل؟

تستخدم المقارنة الخيارات السبعة الواردة في موجز المقال وصفحات المنتجات الأصلية التي روجعت في 14 نوفمبر 2026. ومعايير الاختيار هي نطاق الاستبدال واستمرارية قاعدة البيانات ودعم الهوية والملفات والسلوك اللحظي والتحكم في الاستضافة والعرض المدفوع المبدئي ومسؤولية الترحيل.

لم تُجرَ تجارب بحسابات مسجّلة أو اختبارات لمعدل المعالجة أو قياسات لزمن الاستجابة. التوصيات أحكام معمارية تستند إلى القدرات الموثّقة. والفارق المهم هو ما إذا كان الخيار يلبّي متطلبك بإجمالي عمل أقل على التطبيق، لا عدد مسميات الخصائص على صفحته الرئيسية.

مزوّدو الاستضافة العامة ليسوا بدائل إضافية للخلفية هنا: استئجار خادم وحده لا يستبدل المصادقة أو صلاحيات الملفات أو واجهات التطبيق. تُدرج خدمة قاعدة البيانات عندما توفّر وجهة ترحيل مفيدة، مع توضيح ما يبقى من عمل على الخدمات الأخرى.

خيارات ينبغي تجنّبها في هذه الحالات

تجنّب PocketBase لترحيل إنتاجي حرج لا تستطيع صيانته. تحذير الجهة المطوّرة معيار اختيار، وليس ملاحظة هامشية يمكن تجاوزها بالتبرير.

تجنّب Amplify إن لم يتولَّ أحد مسؤولية إعداد خدمات AWS. نقطة البداية المُولّدة لا تلغي ضرورة فهم الموارد التي تقف وراءها.

تجنّب مسار Firestore في Firebase أو Convex إذا كان الهدف الوحيد نقل SQL قائم. يقدّم كلاهما أسبابًا لاختيار نموذج برمجته، لكن أيًا منهما لا يلغي إعادة كتابة SQL.

تجنّب افتراض أن خلفية Neon الموسّعة تضمن التوافق مع Supabase. تحقّق من كل خدمة ستستبدلها، خصوصًا إذا كان التحديث اللحظي التجريبي أساسيًا للتطبيق.

وتجنّب نقل تطبيق Supabase يعمل جيدًا لمجرد ملاحقة مخصصات مجانية. أثبت أولًا أن البديل يحل مشكلة تفوق كلفة الترحيل والتشغيل المستمر.

أسئلة شائعة

هل Supabase خيار جيد أم سيئ؟

يناسبك Supabase عندما تريد Postgres مع مصادقة وملفات ودوال على الخادم متكاملة. ولا يناسبك عندما تتطلب احتياجات التطبيق أو التشغيل نموذجًا مختلفًا. وجود SQL وسياسات وصول قائمة سبب لتقييم البقاء قبل التبديل.

ما البدائل الجيدة لـ MongoDB؟

هذه مقارنة مختلفة عن استبدال Supabase. إذا كان الهدف بيانات تطبيق قائمة على المستندات، فافحص Firestore أو Convex؛ وإذا كان الهدف الانتقال إلى SQL علائقية، فافحص أحد خيارات Postgres. ولا يعني أي من الاختيارين توافقًا تلقائيًا مع تطبيق MongoDB قائم.

هل يمكن استخدام Supabase مجانًا؟

نعم. تتضمن صفحة خطط Supabase الحالية فئة Free بمخصصات للموارد. ومدى ملاءمتها لتطبيقك يتوقف على الخدمات والاستخدام المطلوبين؛ فالوصول المجاني ليس سعة إنتاج غير محدودة.

هل Supabase وFirebase شيء واحد؟

لا. يلبي كلاهما احتياجات خلفية شائعة، لكن Supabase يتمحور حول Postgres. يستخدم مسار Firestore في Firebase المستندات ومزامنة العملاء، بينما يمثّل SQL Connect مسارًا منفصلًا مدعومًا بـ PostgreSQL. قارن البنية المحددة التي تنوي استخدامها.

هل يوجد خيار أفضل من Supabase؟

يوجد خيار أنسب لمتطلب معيّن: Appwrite لحزمة واسعة قابلة للاستضافة الذاتية، وNeon لانتقال يحافظ على أولوية Postgres، وNhost لـ GraphQL، وFirebase لمسار عمل الجوّال في Firestore، وConvex لدوال البيانات التفاعلية. دون متطلب ملموس، يكون البقاء غالبًا القرار الأفضل.

لماذا سيُغلق Firebase Studio؟

توثّق Google إنهاء Firebase Studio في 22 مارس 2027، وتوجّه مستخدمي مساحات العمل الحاليين نحو Google AI Studio أو Google Antigravity. ولا يثبت إشعار Studio دافعًا تجاريًا أوسع، ويذكر صراحة أن منتجات Firebase الأساسية والتطبيقات المنشورة بالفعل لا تتأثر.

ما الذي سيحل محل Google Firebase؟

لا يوجد بديل واحد لخلفية Firebase في الإشعار أعلاه. وجهات الانتقال المذكورة فيه تخص بيئة تطوير Firebase Studio. لا تختر خلفية بديلة إلا إذا كان نموذج قاعدة بياناتها أو استضافتها أو تطبيقها أنسب لاحتياجاتك.

ما عيوب استخدام Firebase؟

في مسار Firestore، يحتاج تطبيق SQL قائم إلى نموذج مختلف للبيانات والاستعلامات. وتبقى خدمات الإنتاج مرتبطة ببنية Google المُدارة، بينما تستلزم الفوترة بحسب الاستخدام متابعة على مستوى الموارد. كما لا يشمل Spark كل الخدمات اللازمة لخلفية متكاملة.

ما الذي يحدث لـ Firebase؟

يجري إنهاء Firebase Studio، بينما تؤكد Google أن منتجات خلفية Firebase الأساسية لا تتأثر. لا تخلط بين دورة حياة منتج مساحة العمل وتوفر Firestore أو Authentication أو خدمات الخلفية الأخرى.

استخدم قائمة تدقيق سير عمل الأعمال بالذكاء الاصطناعي لرسم سير العمل الذي يجب أن تدعمه خلفيتك قبل الالتزام بالترحيل.