« MongoDB أم PostgreSQL؟ » صار سؤالًا أدقّ ممّا كان عليه قبل خمس سنوات. نوع JSONB في PostgreSQL يستوعب 80 إلى 90% من الحالات التي كنّا سنختار فيها MongoDB بحدس 2018، مع مزايا إضافية: معاملات متعدّدة الجداول، ضمّ علاقي فعّال، ومنظومة SQL مفتوحة. يشرح هذا الدليل الأسئلة السبعة التي تحسم القرار فعلًا، يكشف العتبات الرقمية التي عندها يصير MongoDB خيارًا أفضل، ويُوضّح كلّ تسوية بحالة إنتاج ملموسة على MongoDB 8.0 LTS وPostgreSQL 18 (أو 17 LTS إن كان مدعومًا).
المتطلّبات
- معرفة أساسية بالمحرّكين: نموذج علاقي SQL من جهة، نموذج مستندي BSON من جهة.
- قراءة، إن أمكن، دليل نمذجة MongoDB embedded vs referenced.
- لا تثبيت مطلوب — هذا الدليل مفاهيمي لا تشغيلي.
- الوقت المتوقّع: 70 دقيقة لاستكمال الخطوات التسع لشبكة القرار.
الخطوة 1 — الأرضية المشتركة في 2026
الحقيقة الأولى الواجب التعرّف عليها: في 90% من المشاريع عند الانطلاق، الاختيار بين MongoDB وPostgreSQL لا أثر تقنيًّا قابلًا للقياس له. الاثنان يُديران بضعة ملايين مستند بلا صعوبة، كلاهما يدعم الفهارس الثانوية، كلاهما يكشف وضع JSON أصلي. الجدل « NoSQL مقابل SQL » الذي اشتعل في 2014 انحلّ إلى حدّ بعيد — PostgreSQL أدمج JSONB وحسّنه، وMongoDB أضاف المعاملات متعدّدة المستندات والتكتيب التصريحي للمخطّط.
ما يبقى وجيهًا فعلًا في 2026 هو النظر إلى قمّة منحنى استعمال تطبيقك: ما النمط المهيمن على المدى البعيد، لا في البداية. الاختيار الصحيح هو الذي لن يُقلَب بعد سنتين. الشبكة الآتية تطرح سبعة أسئلة تُعطي إجاباتها مجتمعةً حُكمًا متينًا.
الخطوة 2 — أربعة أسئلة قرار سريعة
قبل الغوص في التفصيل، أربعة أسئلة تحلّ 80% من الحالات. إن أجبت بـ « نعم » على واحد منها على الأقلّ، فـ MongoDB مرشّح جدّي. إن أجبت بـ « لا » على الأربعة، فـ PostgreSQL على الأرجح الخيار الافتراضي الأفضل.
- هل يتغيّر مخطّطك في كلّ sprint؟ خصائص جديدة تُضاف على منتج كلّ أسبوع، أنواع مستندات تظهر مع تطوّر العمل.
- هل لديك كيانات فرعية مفتوحة الحجم تُقرأ معًا؟ ملف مستخدم بمصفوفة تفضيلات اعتباطية، مقال بأقسام متغيّرة.
- هل ستتجاوز كتاباتك 10,000 ops/ثانية مستدامة؟ سجلّات تجارية، أحداث تحليلات، استيعاب مستشعرات.
- هل الـ sharding الأفقي ضرورة متوقّعة؟ حجم مستهدف > 500 جيغا أو نشاط متعدّد المناطق active-active.
ثلاث أو أربع « نعم »: MongoDB دون تردّد. واحدة أو اثنتان: انظر إلى السؤال 6 حول التقارير، الذي يقلب التوازن غالبًا. صفر « نعم »: PostgreSQL مع JSONB للأعمدة المرنة، أبسط وأمتن.
الخطوة 3 — حجم الكتابات
العتبة التجريبية التي عندها يصير MongoDB أكثر راحة من PostgreSQL للكتابات الصرفة هي حوالي 10,000 ops/ثانية مستدامة. دونها يصمد الاثنان: PostgreSQL يستوعب 5,000 إدراج/ث على جدول مُجَزَّأ جيّدًا دون عناء. فوقها، يستفيد MongoDB من journal كتابة مُحَسَّن للإدراجات المتسلسلة، ومن per-CPU TCMalloc المُقَدَّم في 8.0، وإمكان sharding الاستيعاب على عدّة عقد primary.
ثلاث حالات نمطية يقلب فيها هذا المعيار التسوية: منصّة استيعاب أحداث analytics تجمع ملايين الأحداث يوميًّا؛ نظام سجلّات مركزية يُغذِّيه مئات الوكلاء؛ خلفية IoT تتلقّى قياسات من آلاف المستشعرات. في الحالات الثلاث، MongoDB هو الخيار الذي يمرّ إلى التوسيع دون رقصات بهلوانية. في تطبيق معاملاتي تقليدي (CRM، تجارة إلكترونية، SaaS B2B)، نبقى دون العتبة بكثير وPostgreSQL أكثر من كافٍ.
الخطوة 4 — قابلية المخطّط للتطوّر
مخطّط يتطوّر كلّ sprint هو ألدّ أعداء هجرات PostgreSQL. ALTER TABLE ADD COLUMN على جدول بـ 50 مليون سطر قد يستغرق عدّة دقائق ويتطلّب نافذة صيانة، حتى مع تحسينات lock-free في Postgres 17 و18. بالعكس، يخزّن MongoDB كلّ مستند مستقلًّا: إضافة حقل تعني وضعه في المستندات الجديدة وترك القديمة بلا هذا المفتاح.
يثقل هذا المعيار حين يتكرّر التغيير: منتجات بسمات متغيّرة حسب الفئة، محتوى تحريري بنية في تطوّر، ملفّات مستخدمين بحقول تُضاف مع المزايا الجديدة. لتحديد كلفة هذه المرونة، يقدّم MongoDB تحقّقًا تصريحيًّا عبر $jsonSchema — تكسب المرونة المستندية دون فقدان العقد. PostgreSQL JSONB يُتيح مرونة مقارنة لكن بكلفة: فهارس GIN على JSONB أقلّ كفاءة من فهارس B-tree الأصلية في MongoDB، خصوصًا على استعلامات range والفرز.
الخطوة 5 — معاملات متعدّدة الجداول حرجة
هذا المعيار يقلب التسوية في الاتّجاه الآخر. إن كان عملك تهيمن عليه معاملات تضمّ عدّة جداول — محاسبة، مدفوعات، إدارة مخزون بحركات متقاطعة —، فـ PostgreSQL يبقى الخيار الطبيعي. محرّكه ACID ناضج، المعاملات المتداخلة (savepoints) متينة، الـ triggers والإجراءات المخزّنة تُتيح ضمان ثوابت على مستوى القاعدة.
يدعم MongoDB المعاملات متعدّدة المستندات منذ 4.0 وعبر الـ shards منذ 4.2 — متاحة ووظيفية في 2026. لكن بقيدين عمليّين. واحد: على المعاملة في MongoDB أن تنتهي خلال أقلّ من 60 ثانية (transactionLifetimeLimitSeconds)، وإلّا تُلغى. اثنان: كلفة المعاملة محسوسة — 30 إلى 60% كلفة إضافية على الكتابات المعنيّة. لنظام مالي حيث كلّ عملية معاملاتية، يبقى PostgreSQL أكثر أداءً وأكثر قابلية للتنبّؤ.
الخطوة 6 — التقارير والتحليلات
هذا المعيار كثيرًا ما يُستهان به. لـ PostgreSQL أفضلية ساحقة في التقارير: ضمّ متعدّد الجداول عالي الأداء، دوالّ تحليلية SQL (OVER، PARTITION BY، WINDOW)، تكامل أصلي مع أدوات BI (Metabase، Apache Superset، Looker). كلّ الثقافة التحليلية في السوق تتكلّم SQL — هي لغة Tableau، Power BI، dbt.
يردّ MongoDB بـ aggregation pipeline الذي يفوق SQL في بعض الحالات (أنابيب متفرّعة بـ $facet، نوافذ ديناميكية) لكنّه أقلّ شمولًا في أدوات الطرف الثالث. القاعدة العملية: إن كانت نصف ساعات الهندسة ستُصرف على لوحات تحكّم وتقارير متعدّدة المجموعات، فـ PostgreSQL أبسط. إن كانت التحليلات ثانوية والاستعمال الرئيسي تطبيقي، فـ MongoDB مع تجسيد عبر $merge يستدرك الفارق بكثير.
| الحاجة | راحة PostgreSQL | راحة MongoDB |
|---|---|---|
| ضمّ 4-5 جداول | أصلي، مُحَسَّن | $lookup متسلسل، أقلّ أداءً |
| نافذة منزلقة | WINDOW قياسي |
$setWindowFields منذ 5.0 |
| موصِّل BI | دائم الحضور | Atlas BI Connector (مدفوع)، MongoDB Connector لـ Tableau |
| عرض مُجَسَّد | MATERIALIZED VIEW قياسي |
$merge في pipeline، يعمل لكنّه أقلّ تصريحيّة |
الخطوة 7 — التوسيع الأفقي (sharding)
الـ sharding هو الحجّة التاريخية لـ MongoDB. وُلِد scale-out منذ البداية، ويعرض آليّة مدمجة: اختيار shard key، تفعيل sharding على المجموعة، يُوزّع المحرّك تلقائيًّا الـ chunks بين الـ shards ويُوجّه الاستعلامات عبر mongos. يعرض PostgreSQL Citus (امتداد اشترته Microsoft، مدموج في Azure Cosmos DB for PostgreSQL) يُقدّم منطقًا مشابهًا — لكنّه طبقة إضافية، لا سلوك أصلي.
متى يصير الـ sharding ضروريًّا فعلًا؟ ما فوق 500 جيغا من البيانات الساخنة (التي لا تعود تتّسع في RAM آلة معقولة)، أو فوق 50,000 ops/ثانية على عقدة واحدة. دون هاتين العتبتين، replica set في MongoDB أو PostgreSQL مع تقسيم range يكفي. فوقهما، يعرض MongoDB أقلّ الطرق احتكاكًا: sh.shardCollection("ecom.events", { user_id: "hashed" })، والمحرّك يفعل الباقي.
الخطوة 8 — الـ stack وخبرات الفريق
المعيار الأكثر إهمالًا في الهندسة: خبرات الفريق تزن قدر الميزات التقنية. لـ PostgreSQL جيلان من الـ DBAs ومطوّري SQL في السوق: العثور على شخص قادر على تحسين استعلام PostgreSQL يستغرق ساعة من التوظيف. لـ MongoDB مجتمع أصغر سنًّا، أكثر توجّهًا نحو Node.js وPython — الخبرة موجودة لكنّها أندر وأغلى على الملفّات الـ senior.
التسوية العملية: إن كان فريقك من عالم Java/.NET بثقافة SQL قويّة، فالبدء على PostgreSQL يُسرّع التطوير. إن كان فريقك من عالم Node.js/JavaScript بألفة طبيعية للكائنات المتداخلة وBSON، فـ MongoDB أكثر طبيعية. هذا التناسب الثقافي لا يظهر في أيّ benchmark لكنّه يُحدّد جودة كود الإنتاج على سنتين.
الخطوة 9 — Stack هجين PostgreSQL + MongoDB
سؤال متكرّر: أيمكن استعمال الاثنين في الوقت ذاته؟ الجواب: نعم، ممكن وأحيانًا أمثل — لكنّه أيضًا أكثر الفخاخ التشغيلية شيوعًا. ثلاثة أنماط هجينة تشتغل جيّدًا.
النمط 1 — PostgreSQL رئيسي + MongoDB للسجلّات/الأحداث. يستضيف PostgreSQL البيانات المعاملاتية (طلبات، حسابات، مدفوعات)، ويستضيف MongoDB التدفّقات العالية الحجم غير الحرجة (سجلّات تدقيق، أحداث analytics، telemetry). كلّ قاعدة تلعب في ميدان قوّتها.
النمط 2 — PostgreSQL للمصدر الرسمي، MongoDB لذاكرة عروض. تُكتَب البيانات في PostgreSQL (مصدر الحقيقة)، ومهمّة تنسخ دوريًّا إلى MongoDB عروضًا مُسَطَّحة مُحَسَّنة للقراءة (كتالوج منتج، ملف مستخدم مُغنى). MongoDB لم يعد المصدر بل يخدم الشاشات عالية تردّد القراءة.
النمط 3 — MongoDB رئيسي + PostgreSQL للتقارير. العكس: يخزّن MongoDB العمل (مخطّط يتطوّر كثيرًا، كتابات ضخمة)، ويستلم PostgreSQL تصديرًا دوريًّا (عبر Airbyte أو Debezium أو خطّ خاصّ) لتنفيذ لوحات BI. الكلفة التشغيلية تتضاعف لكنّنا نجني خير العالمين.
ما يجب تجنّبه: المعماريات حيث تُكتَب البيانات نفسها على الطرفين بالتوازي مع منطق تطبيقي للحفاظ على التزامن. هذا ضمان لاختلال خفيّ، أخطاء صعبة الاستنساخ، وديْن تشغيلي يتراكم. محرّك واحد فقط مصدر الحقيقة، والثاني انعكاس — واتّجاه التدفّق يجب ألّا ينعكس أبدًا.
الأخطاء الشائعة
| الخطأ | السبب | الحلّ |
|---|---|---|
| اختيار MongoDB لتطبيق CRUD كلاسيكي | أثر موضة 2018، مخطّط ثابت و1000 مستخدم | PostgreSQL مع JSONB على الأعمدة المرنة يكفي |
| اختيار PostgreSQL لاستيعاب IoT ضخم | حدس SQL، جهل العتبات | MongoDB أو TimescaleDB حسب الملف الزمني |
| هجين بكتابة مزدوجة تطبيقية | « نُبقي الخيارين مفتوحَين » | عيّن مصدر حقيقة واحدًا، نَشَر عبر CDC (Debezium) |
| اختيار MongoDB دون اعتبار المعاملات | تطبيق مالي، جهل كلفة المعاملات | PostgreSQL للخدمات المعاملاتية، MongoDB للباقي |
| هجرة سابقة لأوانها Postgres ← Mongo | حدّ مفترض غير مقيس | قِس قبل الهجرة: pg_stat_statements، حدّد hotspots |
الأسئلة الشائعة
س: هل JSONB في PostgreSQL يحلّ محلّ MongoDB تمامًا؟
ج: لـ 80 إلى 90% من الحالات الاعتيادية، نعم. الـ 10 إلى 20% الباقية تتعلّق بالـ sharding الأفقي، الكتابات الضخمة، وaggregation pipeline الأقوى. ما دام أيّ من هذه المحاور غير حرج، يغطّي JSONB على نطاق واسع.
س: هل MongoDB أسرع من PostgreSQL في القراءة؟
ج: على مستند واحد مقروء بمفتاح أساسي، الاثنان متكافئان (بضعة أجزاء من الثانية). على قراءات تستلزم ضمّ جداول، PostgreSQL أسرع. على قراءات تعتمد مخطّطًا متداخلًا عميقًا، MongoDB أسرع لأنّه يتجنّب الضمّ.
س: أيمكن الهجرة من MongoDB إلى PostgreSQL لاحقًا؟
ج: نعم، لكنّه عمل غير تافه. المخطّط المستندي يجب تجزيئه إلى جداول، المراجع الضمنية تُحلّ، الفهارس تُعاد بناؤها. أدوات ممكنة: Airbyte بموصِّل MongoDB ← PostgreSQL، أو سكربت ETL خاصّ. احسب أسابيع لقاعدة إنتاج.
س: Vector search: pgvector أم Atlas Vector Search؟
ج: pgvector إن كنت أصلًا على PostgreSQL — الامتداد ناضج ومدمج جيّدًا. Atlas Vector Search إن كنت على Atlas — مدمج في العنقود دون نشر منفصل. لأحجام شعاعية ضخمة جدًّا، يبقى متخصّصون كـ Pinecone أو Qdrant وجيهين.
س: هل السوق يوظّف PostgreSQL أم MongoDB أكثر؟
ج: PostgreSQL أكثر طلبًا في المؤسّسات والهياكل المالية. MongoDB أكثر طلبًا لدى ناشري SaaS والشركات الناشئة الموجَّهة بالمنتج. الراتب متكافئ بنفس الأقدمية، مع أفضلية صغيرة لـ MongoDB في ملفّات Atlas/Cloud.
للتعمّق
- MongoDB: NoSQL في الممارسة — نقطة دخول مسار MongoDB.
- نمذجة MongoDB embedded vs referenced — القرار الداخلي في عالم المستندات.
- Aggregation Pipeline متقدّم — البديل عن SQL في التقارير.
- MongoDB Compare — official PostgreSQL comparison — الموقف الرسمي لـ MongoDB Inc.