VPS لقاعدة بيانات

توجد لحظة محدّدة تتوقّف فيها قاعدة بيانات مُدارة عن كونها مريحة وتصبح جدارًا. تريد امتدادًا لا تقدّمه الطبقة. تريد رؤية خطة الاستعلام الفعلية وضبط work_mem. تريد superuser. الخدمة المُدارة افتراضٌ رائع حتى تحتاج امتلاك الشيء — وعندها VPS بصلاحية root كاملة هو الجواب الصادق.

هذه الصفحة عن تشغيل PostgreSQL أو Redis الخاص بك بشكل صحيح، وعن الوضوح حول أين يكون الخادم المشترك القرار الصحيح وأين لا.

ما تحتاجه قاعدة البيانات فعلًا

تهتمّ قواعد البيانات بأمرين لا يهتمّ بهما خادم ألعاب: ذاكرة لمجموعة العمل وإدخال/إخراج القرص. الشكل التقريبي:

• تطبيق واحد — نسخة Postgres (أو Redis) مع خدمة خلفية. مجموعة العمل عادةً 1.7-2 GB. Small (8$) يتولّاها دون دراما.
• بضعة تطبيقات، أو تزامن إنتاج حقيقي — اتصالات أكثر، ذاكرات تخزين مؤقت أكبر، مهام خلفية. Medium (12$) يمنحك المساحة.
• أجهزة أخرى تحتاج الوصول إليها — تريد عنوانًا ثابتًا قابلًا للتوجيه، فخطة IPv4 مخصّص (Small-IP من 16$). المزيد أدناه.

Redis أخفّ أيضًا — إنه مقيّد بالذاكرة، فحدّد الخطة بمجموعة بياناتك إضافة إلى العبء وانتهيت. Postgres هو الذي يكافئ قليلًا من الضبط.

السبب الحقيقي للاستضافة الذاتية: التحكم

هنا يكسب VPS مكانه. على خادمك الخاص تحصل على:

• كامل postgresql.conf — shared_buffers وwork_mem وmax_connections وإعدادات WAL، كلها، مضبوطة لحملك بدل افتراضات مورّد.
• أي امتداد. pgvector للتضمينات والبحث الدلالي، PostGIS للبيانات الجغرافية، TimescaleDB للسلاسل الزمنية، pg_cron، pg_stat_statements — ثبّت ما تحتاج. الطبقات المُدارة كثيرًا ما تقيّد قائمة الامتدادات أو تحصرها خلف خطة أعلى.
• superuser ونظام التشغيل تحته. يمكنك نقل دليل البيانات، وضبط النواة، وتشغيل pg_dump بجدولك الخاص، وإعداد نسخ تدفّقي إلى خادم آخر إن أردته.

إن لم يهمّك أيٌّ من ذلك، فقاعدة بيانات مُدارة مناسبة فعلًا ويجب أن تستخدمها. هذه الصفحة للحالة التي يهمّ فيها.

أين يكون الخادم المشترك الأداة الخاطئة

بصراحة: VPS بـ vCPU مشترك ليس مبنيًا لـOLTP ثقيل — مئات المعاملات في الثانية بكتابات حرجة زمنيًا. ذلك الحمل يحيا أو يموت على إدخال/إخراج قرص مضمون وتردّد ثابت، والخطط المشتركة لا تعد بأيّهما. إن كان ذلك حالك، تريد عتادًا مخصّصًا، ونفضّل إخبارك الآن على مشاهدة زمن استجابة p99 يُحرجنا معًا.

للحالة الأكثر شيوعًا — قاعدة بيانات خلف تطبيق واحد، أداة داخلية، مخزن تحليلات، ذاكرة تخزين مؤقت — خطة مشتركة مناسبة تمامًا.

النسخ الاحتياطية ليست اختيارية

الاستضافة الذاتية تعني أن النسخ الاحتياطية مهمّتك، والقاعدة الوحيدة: افعلها قبل أن تحتاجها. لـ Postgres، pg_dump على cron للنسخ المنطقية، أو أرشفة WAL للاستعادة إلى نقطة زمنية لأي شيء تهتمّ به فعلًا. اشحن النسخ خارج الخادم — إلى تخزين كائنات أو خادم آخر — كي لا يأخذ قرص ميت النسخ معه. اختبر استعادة مرة واحدة على الأقل. نسخة لم تستعدها قطّ أملٌ، لا نسخة احتياطية.

السماح لخوادم أخرى بالاتصال

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

1. تحتاج عنوانًا ثابتًا قابلًا للتوجيه — تلك خطة IPv4 مخصّص (Small-IP 16$، Medium-IP 20$). خطط NAT تشارك عنوانًا، وهو مناسب للصادر لا لكونك قاعدة بيانات تتصل بها خوادم أخرى.
2. تقيّده بجدار الحماية بقوة. افتح 5432 (أو 6379) فقط لعناوين IP المحدّدة التي تحتاجه، لا لـ 0.0.0.0/0 أبدًا، واطلب TLS. منفذ Postgres مفتوح على الإنترنت العام يُكتشَف خلال دقائق.

اختيار الخطة

معظم قواعد البيانات المُستضافة ذاتيًا تبدأ على Small وتنمو إلى Medium أو خطة بـ IP مخصّص مع تحمّلها تطبيقات أكثر أو عملاء خارجيين.

لماذا هنا

صلاحية root الكاملة تعني أنها قاعدة بياناتك، حتى القاع — كل سطر إعداد، كل امتداد، جدول نسخك الاحتياطية الخاص، دون طبقة تقرّر ما يُسمح لك بتثبيته. الدفع بالعملات المشفّرة (USDC أو USDT على Base أو Ethereum أو Polygon)، بدون KYC، دون وثائق. صلاحية root خلال 60 ثانية تقريبًا بعد الدفع، ويمكن أن يقبل Postgres اتصالات بعد دقائق قليلة.

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