PostgreSQL مُدارة مع Coolify: دليل الإنتاج 2026

Coolify v4.0+ يدير قواعد بيانات PostgreSQL كخدمة أصلية: إنشاء، نسخ احتياطي، استعادة، monitoring — كلها في واجهة واحدة. هذا يجنّبك تركيب PostgreSQL يدوياً، إدارته، تأمينه. هذا الدرس يقدم 8 خطوات لتشغيل PostgreSQL على Coolify بمستوى إنتاج، مع مقارنة بـ DigitalOcean Managed Databases وSupabase.

المتطلبات

• Coolify v4.0+ مثبّت على VPS
• VPS بـ 2 GB RAM على الأقل (4 GB موصى)
• قرص SSD (لأداء PostgreSQL)
• الوقت المقدر: ساعة ونصف

الخطوة 1 — إنشاء قاعدة بيانات

Coolify يقدم 8+ نسخ من PostgreSQL (12 إلى 18). الإعداد يستغرق دقيقتين.

# في لوحة Coolify:
1. Project → Resources → New Database
2. اختر "PostgreSQL"
3. الإصدار: 18 (الأحدث المستقر، فبراير 2026)
4. الإعدادات:
   - Name: production-pg
   - Database name: myapp
   - User: app_user
   - Password: قوي وعشوائي (16+ char)
5. Resources:
   - Memory: 2 GB
   - Storage: 20 GB (يمكن توسعتها لاحقاً)
6. Deploy

Coolify يبدأ container PostgreSQL في 30 ثانية. الوصول الافتراضي: داخل شبكة Coolify فقط (آمن). للاتصال من خارج، تحتاج فتح port — تجنب ذلك إن أمكن، استخدم Coolify Tunneling أو SSH tunnel للأمان.

الخطوة 2 — Connection strings

بعد الإنشاء، Coolify يعطي 3 connection strings مختلفة:

# 1. Internal (داخل Coolify فقط، الأكثر أماناً):
postgresql://app_user:password@production-pg.coolify-network:5432/myapp

# 2. Public (إن فتحت port):
postgresql://app_user:password@your-vps-ip:5432/myapp

# 3. Pooled connection (مع pgBouncer إن فعّلته):
postgresql://app_user:password@production-pg-pooler:6432/myapp

للتطبيقات المُستضافة على نفس Coolify، استخدم Internal دائماً — لا يمر عبر الإنترنت العام، أسرع وأكثر أماناً. للتطبيقات الخارجية (مثل Vercel)، Public مع SSL إلزامي. لا تستخدم اتصالاً غير مشفّر مع كلمة مرور حقيقية.

الخطوة 3 — تفعيل النسخ الاحتياطي

Coolify يدمج backups إلى S3 (أو R2/MinIO). تفعيلها = حماية قاعدتك من حوادث VPS.

# Database → Backups → Configure:
1. Schedule: 0 3 * * * (3 صباحاً يومياً)
2. Retention: 30 days
3. Storage: production-backups (S3 من فصل سابق)
4. Compression: gzip (يوفر 70-80% مساحة)
5. Encryption: enabled
6. Save

# اختبر فوراً: Run Backup Now
# يجب أن تكتمل في 1-5 دقائق

Cron schedule « 0 3 * * * » = الـ 3 صباحاً يومياً (الأقل ازدحاماً عادة). للقواعد الكبيرة (> 10 GB)، فكّر في incremental backups مع pg_basebackup + WAL archiving بدل dumps كاملة. لكن لـ 90% من المشاريع، dump يومي مضغوط كافٍ.

الخطوة 4 — Tuning أساسي للأداء

إعدادات PostgreSQL الافتراضية محافظة جداً (مصممة لـ 1 GB RAM). على VPS بـ 4 GB، ضبط بسيط يضاعف الأداء.

# Coolify → Database → Configuration → Custom Config:
shared_buffers = 1GB         # ¼ من الـ RAM
effective_cache_size = 3GB   # ¾ من الـ RAM
work_mem = 16MB              # لكل query
maintenance_work_mem = 256MB # لـ VACUUM، CREATE INDEX
max_connections = 100        # لا ترفعها كثيراً، استخدم pooler
random_page_cost = 1.1       # لـ SSD (4.0 لـ HDD)
effective_io_concurrency = 200 # لـ SSD

أداة مساعدة: pgtune.leopard.in.ua تولّد إعدادات مخصصة بناء على RAM، CPU، نوع التخزين. ضع النتيجة في Custom Config، أعد تشغيل Coolify. لا تكثر من max_connections — كل اتصال يستهلك ذاكرة. استخدم pgBouncer (في الخطوة التالية) لإدارة آلاف الاتصالات بـ 100 فعلية.

الخطوة 5 — pgBouncer للـ Connection Pooling

التطبيقات الحديثة (Next.js على Vercel، Lambdas) تفتح اتصالات كثيرة، تستهلك RAM. pgBouncer يحلّ هذا: 10,000 client connection → 50 PostgreSQL connection.

# Coolify → Add new resource → "pgBouncer"
معدّل Configuration:
  - Database: production-pg
  - Pool mode: transaction (الأكثر مرونة)
  - Max client conn: 1000
  - Default pool size: 25
  - Min pool size: 10

# Connection string الجديد للتطبيقات:
postgresql://app_user:password@pgbouncer:6432/myapp

pool_mode = « transaction » (موصى) يفصل الاتصال بعد كل transaction. « session » لا يفصل، استخدمها فقط إن كنت تستخدم session-level features (LISTEN/NOTIFY، prepared statements). معظم التطبيقات تستفيد من transaction pooling. مع pgBouncer، VPS بـ 4 GB يخدم آلاف العملاء المتزامنين.

الخطوة 6 — Monitoring

قاعدة بيانات بدون monitoring = مفاجآت غير سارة (نفاد disk، ركود استعلامات). Coolify يدمج Grafana + Prometheus لـ dashboard أساسي.

# المؤشرات الأهم لمراقبتها:
1. Connections active vs limit
2. Cache hit ratio (يجب > 99%)
3. Slow queries (> 1 second)
4. Disk usage (تنبيه عند 80%)
5. Replication lag (إن استخدمت replicas)

# query سحرية لـ slow queries:
SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

# تتطلب امتداد:
CREATE EXTENSION pg_stat_statements;

Cache hit ratio < 99% يعني shared_buffers صغير جداً، يجب رفعه. Slow queries > 1s يكشف عن indexes ناقصة أو queries غير محسنّة. أداة pgHero (مجانية، Docker container) تعطي dashboard متخصص لمؤشرات صحة PostgreSQL — أكثر فائدة من Grafana العامة.

الخطوة 7 — High Availability

للمواقع الحرجة، VPS واحد = نقطة فشل. Replicas تحلّ المشكلة. Coolify v4.5+ يدعم streaming replication بإعداد بسيط.

# في Coolify:
1. Database → Replication → Add Replica
2. اختر VPS ثاني (مفضّل في موقع جغرافي مختلف)
3. Replication mode: streaming
4. Auto-failover: enabled

# النتيجة:
Primary (VPS 1): writes + reads
Replica (VPS 2): reads only، يتلقّى التحديثات في الوقت الفعلي
إن سقط Primary: Replica يصبح Primary تلقائياً

للمشاريع الصغيرة، Replica قد تكون overkill. التكلفة: ضعف VPS + ضعف backup. القاعدة: شغّل Replica إن كانت ساعة downtime تكلّف أكثر من 100 USD/شهر إضافية. إن لم يكن، backups يومية + monitoring جيد كافيان.

الخطوة 8 — مقارنة بالبدائل

لمشروع صغير-متوسط (< 1000 user): PostgreSQL على Coolify يكفي بأقل تكلفة. للنمو السريع، Supabase أو Neon يقدمان serverless سهل الاستخدام. للمؤسسات (> 10K user)، RDS أو Aurora لا بديل عنهما. اختر بحسب احتياجاتك الحقيقية، لا الطموحات.

أخطاء شائعة

للمزيد

• Coolify PostgreSQL Docs coolify.io/docs
• PostgreSQL Tuning pgtune.leopard.in.ua
• pgBouncer pgbouncer.org
• pgHero github.com/ankane/pghero

مقالات ذات صلة

• Bun في الإنتاج 2026: الدليل الكامل (وقت تشغيل JavaScript حديث)
• Asyncio في الإنتاج: event loop وTaskGroup والتزامن المُهيكَل
• Virtual threads Java 25 في الإنتاج: Loom، StructuredTaskScope والـ pinning