لماذا إعادة تقييم RDS في 2026
Amazon RDS for PostgreSQL قاعدة بيانات مُدارة متينة، لكن نموذج فوترتها مصمم ليتصاعد بشكل غير خطي مع النمو. يُفوتر كل مكوّن بشكل منفصل: حوسبة النسخة، والتخزين gp3 لكل جيجابايت، وIOPS المُخصصة، وعقد النسخ المتماثل Multi-AZ، والنسخ الاحتياطية التي تتجاوز النافذة المُضمّنة، ونقل البيانات الصادرة. نسخة db.r6g.4xlarge بتوافر عالٍ Multi-AZ مع 500 جيجابايت من تخزين gp3 تتجاوز 3000 دولار شهرياً على us-east-1. تعمل نفس أعباء العمل على كتلة Hetzner Cloud مكونة من ثلاث عقد بحوالي 835 دولار شهرياً — وفراً قدره 2315 دولاراً شهرياً، أي نحو 27800 دولار خلال اثني عشر شهراً (المصدر: selfhost.dev، مايو 2026، HN item #48816129). لقاعدة تطوير أو عبء عمل تجاري بدون نسخة احتياطية، تكفي عقدة واحدة بجزء بسيط من هذه التكلفة. تغيّر المشهد التسعيري أيضاً في 2026: راجعت Hetzner جداولها في أبريل ثم يونيو 2026، وحدّثت OVHcloud أسعار VPS في أبريل 2026. هذه الزيادات تغير الأرقام المطلقة، لا المنطق: تظل الاستضافة الذاتية أرخص هيكلياً متى تجاوزت قاعدة البيانات عشرات الجيجابايتات وفرض الحجم نسخة غير قابلة للتوسع المؤقت.
ما الذي تكسبه بالانتقال إلى VPS
- تكلفة ثابتة وقابلة للتنبؤ — لا فوترة لكل GB أو IOPS إضافية أو اتصالات متزامنة؛ تختار حجم VPS مرة واحدة ولا يتغير السعر مع حجم الاستعلامات.
- امتدادات غير مقيدة — PostGIS وTimescaleDB وpg_partman وpgvector وcitus: لا قيود تعسفية، بخلاف RDS حيث القائمة مغلقة والامتدادات غير المدعومة غائبة.
- وصول root وإعداد دقيق —
postgresql.confوpg_hba.confوhuge_pagesوwal_levelوموحّدات الاتصال: ضبط كل معلمة دون المرور بلوحة تحكم سحابية ودون قيود على أدوات النظام. - تحكم بالإصدارات — أنت تقرر متى تنتقل من PostgreSQL 16 إلى 17، دون نوافذ صيانة مفروضة أو إيقاف قسري من المزوّد.
- البيانات ضمن نطاقك — اختيار مركز البيانات، وتشفير الأقراص وفق سياستك الداخلية، ودون رسوم نقل البيانات بين المناطق عند كل قراءة تحليلية.
- قابلية النقل الكاملة —
pg_dumpأو النسخ المتماثل المنطقي ينقل بياناتك إلى أي مضيف آخر دون احتكاك بمزود ودون رسوم خروج. - خيار الإدارة متاح — إن كان العبء التشغيلي هو الاعتراض الرئيسي، يغطي خيار إدارة VPS المهام الروتينية (التحديثات والمراقبة والنسخ الاحتياطية)؛ يبقى التحكم بيدك، لا العبء.
PostgreSQL على VPS مقابل Amazon RDS: جدول مقارنة
| المعيار | PostgreSQL على VPS | Amazon RDS for PostgreSQL |
|---|---|---|
| التكلفة الشهرية (عبء عادي) | ثابتة — تتناسب مع الخادم المختار | متغيرة — حوسبة + تخزين + IOPS + Multi-AZ + خروج البيانات |
| مثال التوافر العالي (3 عقد / Multi-AZ) | ~835 $/شهر (Hetzner CCX53، مايو 2026) | ~3150 $/شهر (db.r6g.4xlarge Multi-AZ، us-east-1) |
| امتدادات PostgreSQL | الكل، بما يشمل PostGIS وpgvector وTimescaleDB وcitus | قائمة محدودة؛ الامتدادات غير المدعومة غائبة |
| وصول Root / نظام التشغيل | نعم — اختيار النظام، Docker، cron، ضبط النواة، pgBouncer | لا — واجهة AWS فقط، معلمات مقيدة |
| ترقيات الإصدار | بوتيرتك الخاصة، دون نوافذ مفروضة | مجدولة أو مفروضة من AWS عند الإيقاف |
| العبء التشغيلي | إدارة النسخ الاحتياطية والتحديثات والمراقبة | آلي بواسطة AWS: نسخ احتياطية، تصحيحات، تجاوز فشل |
| قابلية النقل | كاملة — `pg_dump` أو النسخ المتماثل المنطقي، دون رسوم | مرتبطة بنظام AWS البيئي، تصدير البيانات مدفوع |
المتطلبات الأساسية قبل الهجرة
يكفي VPS بذاكرة 4 جيجابايت و2 vCPU لمعظم قواعد بيانات تطبيقات الويب الأصغر من 50 جيجابايت مع حركة مرور متوسطة وأقل من 50 اتصالاً متزامناً. لقاعدة بيانات أكثر مطالبة أو مخطط تحليلي بانضمامات متعددة أو خدمة تواجه ذروات مرور، خطط لـ 8 جيجابايت RAM على الأقل. تخزين SSD NVMe ضروري: يُقلل الوصول العشوائي لـ PostgreSQL على قرص دوّار أو SSD SATA الأداء بشكل ملحوظ، خاصة عند إعادة ملء ذاكرة التخزين المؤقت بعد إعادة التشغيل. الوصول بصلاحيات root مطلوب — وهو معيار على أي VPS سحابي. على صعيد الشبكة، ستحتاج إلى عنوان IPv4 ثابت أو اسم نطاق داخلي لتوجيه اتصالات التطبيق. خطط أخيراً لنافذة هجرة تعمل خلالها قاعدتا البيانات بالتوازي: يشير التطبيق إلى RDS بينما تملأ VPS، وتتحقق من الاتساق، ثم تُبدّل متغير الاتصال.
تثبيت وإعداد PostgreSQL على VPS
تثبيت PostgreSQL من مستودع PGDG الرسمي
على Ubuntu 24.04 أو Debian 12، أضف مستودع PostgreSQL Global Development Group: curl -fsSL https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/postgresql.gpg ثم echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" | sudo tee /etc/apt/sources.list.d/pgdg.list. ثم: sudo apt update && sudo apt install -y postgresql-17.
إنشاء مستخدم وقاعدة بيانات مخصصَين
الاتصال بـ postgres: sudo -u postgres psql. إنشاء مستخدم تطبيق مخصص وقاعدة بيانات معزولة: CREATE USER myapp WITH PASSWORD 'strong-password'; ثم CREATE DATABASE myapp OWNER myapp;. الخروج بـ \q. لا تستخدم حساب postgres في سلسلة اتصال تطبيقك أبداً.
إعداد postgresql.conf وفق الحمل المتوقع
ملف الإعداد موجود في /etc/postgresql/17/main/postgresql.conf. المعلمات الرئيسية لـ VPS بذاكرة 4 جيجابايت: shared_buffers = 1GB (25% من RAM)، effective_cache_size = 3GB، work_mem = 16MB، maintenance_work_mem = 256MB، max_connections = 100. أعد التشغيل بعد أي تعديل: sudo systemctl restart postgresql.
تقييد اتصالات الشبكة في pg_hba.conf
افتراضياً، لا يستمع PostgreSQL إلا على localhost. إذا كان تطبيقك على نفس الخادم فاتركه كما هو. لتطبيق على آلة أخرى، عدّل /etc/postgresql/17/main/pg_hba.conf وأضف: host myapp myapp <IP-التطبيق>/32 scram-sha-256. في postgresql.conf عيّن listen_addresses = 'localhost,<IP-VPS>'. أعد التحميل: sudo systemctl reload postgresql.
التصدير من RDS والاستيراد على VPS
من آلة لها وصول للمضيفَين، صدّر بصيغة الأرشيف المخصص: pg_dump -h <rds-endpoint> -U <user> -Fc <database> -f dump.pgc. ثم استورد على VPS بأربعة عمال متوازية: pg_restore -h localhost -U myapp -d myapp -j 4 dump.pgc. تحقق من عدد صفوف بعض الجداول الحيوية قبل تبديل اتصال التطبيق.
أتمتة النسخ الاحتياطي عبر cron
أنشئ /usr/local/bin/pg-backup.sh: PGPASSWORD='password' pg_dump -U myapp myapp -Fc > /var/backups/pg/myapp-$(date +%Y%m%d-%H%M).pgc. اجعله قابلاً للتنفيذ: chmod +x /usr/local/bin/pg-backup.sh. أضف مدخلة cron: 0 3 * * * /usr/local/bin/pg-backup.sh. احتفظ بالنسخ مشفرة على تخزين خارجي أو انقلها عبر rsync إلى VPS ثانٍ.
تفعيل المراقبة بـ pg_stat_statements
في postgresql.conf، أضف shared_preload_libraries = 'pg_stat_statements'. أعد تشغيل PostgreSQL، ثم فعّل الامتداد في قاعدتك: CREATE EXTENSION pg_stat_statements;. حدّد الاستعلامات البطيئة: SELECT query, mean_exec_time, calls FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;.
التصليب بعد التثبيت: عطّل حساب postgres النظامي لاتصالات SSH (sudo passwd -l postgres)؛ فعّل ssl = on في postgresql.conf مع شهادة Let's Encrypt أو موقّعة ذاتياً لتشفير الاتصالات الشبكية؛ فعّل ufw وافتح المنفذ 5432 فقط لعناوين IP التطبيق المعروفة (sudo ufw allow from <IP-app> to any port 5432). هذه الخطوات الثلاث تغطي سطح الهجوم الأساسي لقاعدة بيانات مكشوفة على شبكة غير خاصة.
استكشاف الأخطاء: الأخطاء الشائعة بعد الهجرة
الأخطاء التالية تظهر بكثرة في الساعات الأولى بعد الهجرة من RDS إلى VPS مستقل. لكل منها رسالة محددة وعلاج مستهدف — اقرأ الرسالة كاملة قبل التصرف، إذ تشترك أسباب مختلفة في نفس كود الخطأ.
خمسة أخطاء شائعة وحلولها
FATAL: password authentication failed for user "myapp"— كلمة المرور المُرسلة لا تتطابق مع المخزنة، أو تختلف طريقة المصادقة (md5مقابلscram-sha-256). تحقق من السطر المقابل فيpg_hba.confوأعد التحميل:sudo systemctl reload postgresql.FATAL: no pg_hba.conf entry for host "<IP>", user "myapp", database "myapp", SSL off— عنوان IP المصدر غير مصرح به فيpg_hba.conf. أضف المدخلة المفقودة لذلك IP وأعد التحميل. إن لم تُرد SSL، تحقق أن السطر يستخدمhostلاhostssl.ERROR: extension "uuid-ossp" does not exist(أو أي امتداد غائب على RDS) — الامتداد متاح لكنه غير مفعّل في هذه القاعدة. نفّذ من psql:CREATE EXTENSION IF NOT EXISTS "uuid-ossp";. إن كان غائباً من الحزمة، ثبّته:sudo apt install postgresql-17-<extension>.FATAL: remaining connection slots are reserved for non-replication superuser connections— وصلmax_connectionsحده الأقصى. ارفعه فيpostgresql.confوأعد التشغيل، أو ثبّتpgBouncerلمشاركة الاتصالات: مجموعة من 10 اتصالات حقيقية يمكنها خدمة مئات عملاء التطبيق.pg_restore: error: could not execute query: ERROR: role "rdsadmin" does not exist— ينشئ RDS أدواراً داخلية غائبة عن أي PostgreSQL خارج AWS. أضف--no-owner --no-privilegesإلى أمرpg_restore:pg_restore --no-owner --no-privileges -h localhost -U myapp -d myapp dump.pgc.
ما لا تغطيه هذه المقارنة — وما يجب معرفته قبل القرار
تنقل الاستضافة الذاتية إلى فريقك مسؤولية إدارة النسخ الاحتياطية وتحديثات الأمان والمراقبة. هذا واقع لا حجة ضد الاستضافة الذاتية — قيّمه مقابل التكلفة الموفَّرة. لمطور منفرد أو فريق صغير يفتقر للخبرة التشغيلية، يغطي خيار إدارة VPS المهام الروتينية دون الحاجة إلى تنسيقها. يظل RDS مناسباً في حالتين محددتين: عندما تكون المرونة متعددة المناطق متطلباً تعاقدياً وتفتقر الموارد اللازمة لتنفيذها يدوياً، وعندما تكون الفوترة بالاستهلاك مفيدة فعلاً لقاعدة بيانات صغيرة جداً نادرة الاستخدام. لكل ما عدا ذلك — قاعدة بيانات متوسطة، عبء عمل مستقر، فريق بمهارات نظامية أساسية — تدعم الأرقام الاستضافة الذاتية بوضوح. تكمّل مقالات <a href="/blog/heberger-postgresql-vps">PostgreSQL على VPS: التثبيت وأفضل الممارسات</a> و<a href="/blog/postgresql-fin-de-vie-planifier-montee-version">نهاية دعم PostgreSQL: التخطيط لترقية الإصدار</a> هذا الدليل من الجانب التشغيلي وإدارة الإصدارات الكبرى.
