Neon أم Supabase؟ التفرع أسرع 23 مرة، لكن المنصة الكاملة لها ثمن

اختر Neon إذا كان مشروعك ينشئ قواعد PostgreSQL وفروعاً كثيرة، ثم يترك معظمها خاملاً. واختر Supabase إذا كان التطبيق يحتاج قاعدة البيانات والمصادقة وتخزين الملفات والتحديثات الفورية ضمن مشروع مترابط. في الحالتين، قارن تكلفة تشغيل PostgreSQL بقيمة خدمات الخلفية التي سيستخدمها المنتج فعلاً؛ فسعر البداية وحده لا يصف الفاتورة ولا جهد البناء.

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

التفرع ونسخ القراءة: أين يظهر فارق السرعة؟

في اختبار DevOps Daily المحدّث في يونيو 2026، والذي ضم 469 عينة، وصلت نسخة القراءة في Neon إلى أول استعلام أسرع 23 مرة في السيناريو المقاس؛ أما الفرع القابل للاستعلام فاستغرق 1.7 ثانية في Neon حاملاً بيانات الأصل، مقابل 6.2 ثانية في Supabase لفرع يحمل المخطط والإعدادات دون الصفوف. هذه نتائج عمليات مختلفة، كما أن الفرعين لم ينتجا نسخة بيانات متماثلة.

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

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

الاستيقاظ والاستعادة: أثرهما على التطبيق

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

تختلف سياسة التوقف لدى Supabase بحسب الخطة: تتوقف المشاريع المجانية بعد خمول ممتد، بينما لا تتوقف مشاريع Pro تلقائياً. وتوضح أسئلة فوترة Supabase أن المشروع الذي يُوقَف لا تُحتسب له ساعات حوسبة أثناء توقفه. غير أن إيقاف مشروع مدفوع يدوياً ليس بديلاً تلقائياً عن قاعدة متاحة لتلقي طلبات التطبيق في أي لحظة.

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

الفاتورة: ساعات الحوسبة ليست سعر المنصة كله

بحسب تسعير Neon، تتيح الخطة المجانية 100 مشروع و100 ساعة حوسبة بوحدة CU شهرياً لكل مشروع و1 غيغابايت لتخزين قاعدته؛ وفي Launch تُسعّر الحوسبة بـ0.106 دولار لكل CU-ساعة، وتخزين قاعدة البيانات بـ0.35 دولار لكل غيغابايت-شهر، والفرع الإضافي بـ0.002 دولار لكل ساعة فرع. تتوقف ساعات الحوسبة عند نزول القاعدة إلى الصفر، لكن التخزين وتاريخ التغييرات والفروع الإضافية والخدمات الخلفية تدخل في الحساب كلٌ وفق بندها.

وتبدأ خطة Supabase Pro من 25 دولاراً شهرياً، وتشمل رصيد حوسبة بقيمة 10 دولارات يكفي مثيل Micro واحداً؛ وتبدأ كلفة المشروع الإضافي من نحو 10 دولارات شهرياً، فيما تبدأ إضافة الاستعادة إلى نقطة زمنية من 100 دولار شهرياً. يتضمن الاشتراك حدود استخدام وخدمات تتجاوز PostgreSQL، لذلك لا يصح التعامل مع رسم Pro كله بوصفه ثمن حوسبة قاعدة واحدة.

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

ما الذي تشتريه مع خدمات الخلفية؟

لم تعد Neon قاعدة بيانات مجردة من الخدمات المصاحبة. يعرض شرح Neon للخطة المجانية خدمات Managed Better Auth وObject Storage وFunctions إلى جانب PostgreSQL. يجعل ذلك المقارنة أدق: المطلوب تحديد وظائف المصادقة والملفات والعمليات التي يحتاجها التطبيق، ثم النظر إلى حدود كل خدمة وطريقة دمجها وفوترتها.

تجمع Supabase داخل المشروع قاعدة PostgreSQL وخدمات Auth وStorage وRealtime وFunctions. تظهر قيمة هذا التجميع عندما يحتاج المنتج إلى حسابات مستخدمين وسياسات وصول وملفات وتحديثات مرتبطة بتغييرات القاعدة في مسار تطوير واحد. وفي المقابل، إذا كان الفريق يستخدم بالفعل خدمات مستقلة للمصادقة أو التخزين، فقد لا يستفيد من كل ما يتضمنه اشتراك المنصة.

وجود Auth وتخزين ملفات لدى الخدمتين لا يعني تطابق تجربة التطوير أو حدود الاستخدام. وتظل Realtime وظيفة ينبغي مقارنتها على حدة إذا كان المنتج يعتمد على بث تغييرات PostgreSQL إلى العملاء. هنا قد يغيّر وقت دمج المكونات وتشغيلها كلفة القرار أكثر من فرق صغير في سعر التخزين أو زمن استعلام عادي.

أي خيار يناسب حملك؟

• مشروع جانبي متقطع: ترجح Neon عندما تنشط القاعدة في دفعات قصيرة وتحتاج فروعاً تحمل بيانات للتجربة، لأن ساعات السكون لا تستهلك حوسبتها. لكن تأخر أول طلب بعد الاستيقاظ يهم إذا كان الزائر يتوقع استجابة فورية. وترجح Supabase حين تكون المصادقة والملفات والتحديثات الفورية جزءاً أساسياً من المشروع منذ بدايته، حتى لو كانت قاعدة البيانات صغيرة.
• تطبيق SaaS يعمل باستمرار: ضع ساعات التشغيل والذاكرة والتخزين وحجم الاستخدام الفعلي في المقدمة؛ فميزة النزول إلى الصفر محدودة حين تبقى القاعدة مشغولة. تمنح Supabase فاتورة اشتراك واضحة للمشروع الذي يستفيد من خدماتها المدمجة، بينما قد تناسب Neon فريقاً يملك تلك الخدمات خارج المنصة ويريد محاسبة موارد PostgreSQL بصورة منفصلة. لا يحسم أي سعر افتتاحي تكلفة الحمل المستمر وحده.
• وكلاء ينشئون قواعد وبيئات كثيرة: تميل الكفة إلى Neon عندما يكون إنشاء المشاريع والفروع الحاملة للبيانات جزءاً متكرراً من سير العمل، ثم تخمد تلك البيئات أو تُحذف. احسب مدة بقاء الفروع، وتخزين التغييرات، وحوسبة الفروع النشطة؛ فعدد مرات الإنشاء وحده لا يصف التكلفة. وإذا كانت البيئة المطلوبة لا تحتاج بيانات الأصل، تختلف قيمة الفرع السريع عن حالة اختبار نسخة واقعية من قاعدة قائمة.
• منتج يحتاج Auth وStorage وRealtime معاً: تستحق Supabase الأفضلية المبدئية إذا أراد الفريق هذه الوظائف مترابطة مع PostgreSQL داخل المشروع. ويمكن بناء خلفية على Neon وخدماتها، لكن يجب مقارنة وظيفة التحديثات الفورية وحدود كل مكون وجهد الربط بينها بحسب متطلبات المنتج. سرعة تجهيز نسخة قراءة لا تعوض خدمة يحتاج الفريق إلى تطويرها وتشغيلها بنفسه.

اقرأ أيضًا:

• إيرلندا تولّد وظائف AI أسرع 3 مرات، لكن الانتشار غير متكافئ
• Factory تقفز إلى 5 مليارات دولار: التقييم تضاعف 16 مرة في عام
• Supabase تجمع 150 مليون دولار وتشتري Turso: وكل وكيل يحصل على قاعدة