n8n على SQLite أم PostgreSQL؟ اختيار قاعدة البيانات لبيئة الإنتاج

فريق تحرير IM Host25 أكتوبر 20266 دقائق قراءة

تخزّن كل نسخة من n8n مسارات العمل (workflows) وبيانات الاعتماد (credentials) وسجل التنفيذات في قاعدة بيانات. افتراضيًا يستخدم n8n قاعدة SQLite، وهي ملف واحد على القرص لا يحتاج إلى تثبيت أي شيء إضافي. هذا مريح في التجربة الأولى، لكن في بيئة إنتاج تستقبل طلبات webhook وتشغّل مهامًا مجدولة طوال اليوم يستحق القرار نظرة أعمق. يقارن هذا الدليل بين الخيارين المدعومين، ويعرض إعداد PostgreSQL الصحيح، ويغطي أمرين يحددان صحة النظام على المدى الطويل: تنظيف بيانات التنفيذ والنسخ الاحتياطي.

ما الذي يحفظه n8n في قاعدة البيانات؟

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

لذلك السؤال الحقيقي ليس "أي قاعدة أسرع؟" بل "أي قاعدة تتحمل تدفقًا مستمرًا من عمليات الكتابة وجدول تنفيذات يكبر باستمرار، ويسهل نسخها احتياطيًا؟".

SQLite: متى تكفي ومتى تصبح عائقًا

SQLite قاعدة بيانات متينة. للاستخدام الشخصي أو بيئة الاختبار أو بضعة مسارات تعمل مرات قليلة يوميًا، تؤدي المطلوب جيدًا، ولا توجد خدمة منفصلة تحتاج إلى تأمين أو مراقبة. توجد القاعدة في ~/.n8n/database.sqlite، أو في /home/node/.n8n/database.sqlite داخل صورة Docker الرسمية.

تظهر الحدود مع زيادة الحمل:

كاتب واحد في كل مرة. تقفل SQLite قاعدة البيانات مع كل عملية كتابة، فتنتظر التنفيذات المتوازية وطلبات webhook بعضها بعضًا، وقد ترى في السجلات الخطأ SQLITE_BUSY: database is locked.
الملف لا يصغر تلقائيًا. التنفيذات المحذوفة تترك صفحات فارغة داخل الملف، ويبقى حجمه على القرص كبيرًا حتى تشغّل عملية vacuum. يمكنك ضبط DB_SQLITE_VACUUM_ON_STARTUP=true، لكن ذلك يجعل كل إعادة تشغيل بطيئة مع الملفات الكبيرة.
لا يناسب وضع الطابور (queue mode). توسيع n8n بعمليات عاملة منفصلة يتطلب قاعدة بيانات تتشاركها عدة عمليات، وتوصي وثائق n8n باستخدام PostgreSQL لهذا الإعداد.
النسخ الاحتياطي يحتاج إلى حذر. نسخ الملف أثناء كتابة n8n عليه قد يعطيك نسخة تالفة.

PostgreSQL: الخيار الافتراضي للإنتاج

تتعامل PostgreSQL مع عمليات كتابة متزامنة كثيرة، وتستعيد المساحة تلقائيًا عبر autovacuum، وتدعم النسخ الاحتياطي أثناء التشغيل عبر pg_dump، وهي القاعدة التي يوصي بها n8n لوضع الطابور. تكلفتها ذاكرة إضافية بسيطة (كقاعدة تقريبية خطّط لبضع مئات من الميجابايت لنسخة PostgreSQL صغيرة) وخدمة إضافية تحتاج إلى تشغيل. وفي أي نسخة يعتمد عليها فريق أو عميل، تستحق هذه المقايضة.

أُعلن إيقاف دعم MySQL وMariaDB في n8n 1.0، لذا فالاختيار العملي في الإعدادات الجديدة للإنتاج هو بين SQLite وPostgreSQL.

إعداد n8n للعمل مع PostgreSQL

يقرأ n8n إعدادات قاعدة البيانات من متغيرات البيئة. يشغّل ملف Docker Compose التالي PostgreSQL وn8n معًا:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-this-password
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-this-password
      N8N_ENCRYPTION_KEY: replace-with-a-long-random-string
      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: 168
      EXECUTIONS_DATA_PRUNE_MAX_COUNT: 10000
      GENERIC_TIMEZONE: UTC
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  pg_data:
  n8n_data:

بعض التفاصيل هنا مهمة:

يجب أن تكون قيمة DB_TYPE هي postgresdb تحديدًا، لا postgres ولا postgresql. وإذا غاب المتغير يعمل n8n على SQLite دون أي تحذير، لذا راجع سجلات بدء التشغيل.
قيمة DB_POSTGRESDB_HOST هي اسم الخدمة postgres. داخل الحاوية يشير localhost إلى الحاوية نفسها، فيظهر الخطأ Error: connect ECONNREFUSED 127.0.0.1:5432.
لا يُطبَّق POSTGRES_PASSWORD إلا عند إنشاء وحدة التخزين (volume) لأول مرة. إذا غيّرته لاحقًا ستحصل على password authentication failed for user "n8n". غيّر كلمة المرور من داخل PostgreSQL عبر ALTER USER، أو ابدأ بوحدة تخزين جديدة.
المنفذ 5678 مربوط بالعنوان 127.0.0.1، فلا يمكن الوصول إلى n8n إلا عبر وكيل عكسي (reverse proxy) مع HTTPS، ولا يُنشر منفذ PostgreSQL للخارج إطلاقًا.
في الإنتاج انقل كلمات المرور ومفتاح التشفير إلى ملف .env بصلاحيات مقيّدة بدلًا من ملف compose.

أنشئ مفتاح تشفير قويًا مرة واحدة واحفظه في مكان آمن:

openssl rand -hex 32

نظّف بيانات التنفيذ قبل أن تملأ القرص

التنظيف (pruning) مفعّل افتراضيًا في n8n 1.x. فهو يحذف التنفيذات الأقدم من EXECUTIONS_DATA_MAX_AGE ساعة (الافتراضي 336، أي 14 يومًا)، ويحتفظ بعدد أقصى قدره EXECUTIONS_DATA_PRUNE_MAX_COUNT (الافتراضي 10,000). اضبط القيمتين بحسب المدة التي تحتاج فعلًا إلى الرجوع إليها عند تتبّع الأخطاء، فسبعة أيام تكفي فرقًا كثيرة.

ويمكنك أيضًا حفظ بيانات أقل من البداية:

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false
N8N_DEFAULT_BINARY_DATA_MODE=filesystem

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

لمعرفة حجم بيانات التنفيذ في PostgreSQL:

docker compose exec postgres psql -U n8n -d n8n -c "SELECT pg_size_pretty(pg_total_relation_size('execution_data'));"

انسخ قاعدة البيانات والمفتاح احتياطيًا

في PostgreSQL، يُنشئ pg_dump نسخة متّسقة بينما يواصل n8n العمل:

docker compose exec -T postgres pg_dump -U n8n -Fc n8n > n8n-$(date +%F).dump

للاستعادة، أوقف n8n أولًا (docker compose stop n8n) ثم نفّذ:

docker compose exec -T postgres pg_restore -U n8n -d n8n --clean --if-exists < n8n-2026-10-25.dump

وفي SQLite استخدم أمر النسخ الاحتياطي المدمج أثناء التشغيل بدلًا من نسخ الملف:

sqlite3 /home/node/.n8n/database.sqlite ".backup '/home/node/.n8n/backup.sqlite'"

تنطبق قاعدتان على القاعدتين معًا. الأولى: انسخ مفتاح التشفير احتياطيًا، فبدون N8N_ENCRYPTION_KEY (أو المفتاح المُنشأ تلقائيًا في /home/node/.n8n/config) لا يمكن فك تشفير بيانات الاعتماد الموجودة في النسخة. الثانية: احتفظ بنسخة خارج الخادم وجرّب الاستعادة مرة واحدة على الأقل، فالنسخة التي لم تُجرَّب استعادتها مجرد افتراض.

الانتقال من SQLite إلى PostgreSQL

أبسط طريق هو تصدير مسارات العمل وبيانات الاعتماد بأداة n8n CLI، ثم توجيه n8n إلى PostgreSQL، ثم استيرادها من جديد. استخدم مفتاح التشفير نفسه في الإعداد الجديد حتى تبقى بيانات الاعتماد قابلة للقراءة.

docker compose exec n8n n8n export:workflow --all --output=/home/node/.n8n/workflows.json
docker compose exec n8n n8n export:credentials --all --output=/home/node/.n8n/credentials.json
# switch DB_TYPE to postgresdb, restart, then:
docker compose exec n8n n8n import:workflow --input=/home/node/.n8n/workflows.json
docker compose exec n8n n8n import:credentials --input=/home/node/.n8n/credentials.json

لا ينقل هذا الأسلوب سجل التنفيذات، وهذا مقبول غالبًا. تأكّد بعد الاستيراد أن مسارات العمل مفعّلة، وأعد تفعيلها إذا لزم الأمر.

الخلاصة

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

شغّله على IM HOST

تأتي استضافة n8n من IM HOST مع n8n مثبّتًا مسبقًا على PostgreSQL مع HTTPS، فتبدأ مباشرة بإعداد الإنتاج الموصوف أعلاه. لا يوجد حد لعدد مسارات العمل أو التنفيذات، وتحتفظ بصلاحيات root كاملة لضبط التنظيف والنسخ الاحتياطي بنفسك. وإذا فضّلت بناء بيئتك بنفسك، فخطط Cloud VPS توفّر أنوية وذاكرة مخصّصة، ونسخة احتياطية تلقائية مجانية كل 3 أيام، وإمكانية الترقية في أي وقت. مهندسونا متاحون على مدار الساعة طوال أيام الأسبوع، ولا توجد رسوم إعداد.