pg_graphql مقابل Hasura وPostGraphile على Postgres

يقوم pg_graphql باستكشاف مخطط SQL الخاص بك وإنشاء مخطط GraphQL يتوافق مع اصطلاح Relay - <table>Collection, edges, node, يقوم بالتصفية حسب نوع العمود، وترقيم الصفحات حسب المؤشر. لا توجد لغة SDL للكتابة أو الصيانة يدويًا: يتبع مخطط GraphQL مخطط Postgres الخاص بك.

النقطة المهمة بالنسبة للهندسة المعمارية: يعيش منشئ المخطط هذا داخل قاعدة البيانات، كوظيفة SQL، وليس كعملية HTTP بجوارها. تقوم Aurabase بتثبيت الإصدار 1.6.1 من الامتداد (تم إصداره في 7 مايو 2026) في صورة Postgres - نفس الحزمة الرسمية .deb التي وزعتها Supabase. يتم تثبيته على المجموعة المشتركة وعلى مثيلات Postgres المخصصة.

إذا كنت قادمًا من Supabase، حيث تم تمكين pg_graphql محليًا لفترة طويلة، فسيكون المنطق مألوفًا لك. تغطي مقارنة التفصيلية ودليل الترحيل بقية مخطط وسياسات RLS، التي تظل كما هي.

لم يختف أي من المنافسين التاريخيين لـ "Instant GraphQL على Postgres". لقد تغير موقفهم، وينبغي أن يعكس المقال المحدث ذلك بدلاً من الاستشهاد بالحالة التي كانت عليه قبل عامين.

نشرت Hasura منشورًا في يونيو 2025 بعنوان صريح، "من GraphQL إلى PromptQL: بداية فصل جديد"، موقع من مؤسسها المشارك Tanmai Gopal. الرسالة: تعيد الشركة تركيز خارطة الطريق الخاصة بها على PromptQL، وهي طبقة وصول إلى البيانات مصممة لعملاء الذكاء الاصطناعي. لم تتم إزالة محرك GraphQL - لا تزال الصفحة الرئيسية لـ Hasura تعرضه على أنه "تم اختباره في المعركة" - ولكنه لم يعد الرسالة ذات الأولوية.

PostGraphileمن جهتها فعلت العكس. أصبح الإصدار 5، قيد التطوير منذ عام 2023 في شكل إصدارات تجريبية، متاحًا بشكل عام في 24 مارس 2026، مع محرك تخطيط استعلام جديد يسمى Grafast. هذا ليس مشروعًا ينفد: الإصدار الأخير، 5.1.4، يعود تاريخه إلى 5 أغسطس 2026. أحصت حزمة npm 119,230 تنزيلًا في الأسبوع من 16 إلى 22 أغسطس 2026 وحده (سجل npm، تمت الرجوع إليه في 23 أغسطس 2026).

الفرق الذي ينظم كل شيء آخر - تكلفة التشغيل، وسطح الهجوم، ووقت الاستجابة - هو مكان تشغيل محرك GraphQL.

لنكون صادقين: تقوم PostGraphile أيضًا بتفويض التفويض إلى Postgres عبر pgSettings وتبديل الأدوار - لا يقتصر RLS الأصلي على pg_graphql. ما يبقى مختلفًا هو من يستضيف هذا الجسر ويقوم بتكوينه: في PostGraphile، أنت هو؛ في Aurabase، تم ذلك بالفعل.

يتم التنشيط بالاشتراك، لكل مشروع، ومخصص لمشاريع محرك Postgres - يرفض مشروع MongoDB الطلب (GRAPHQL_UNSUPPORTED_ENGINE)، pg_graphql هو امتداد Postgres بدون ما يعادله على المحرك الآخر.

عبر CLI أو عن طريق الاتصال مباشرة بخطة الإدارة:

# غير فعال: إن استدعاء مشروع تم تنشيطه بالفعل لا يؤدي إلى إعادة إنشاء أي شيء
aura projects graphql-enable <project_id>

# مكافئ HTTP (مستوى الإدارة، وحدة تحكم JWT)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

من جانب الخادم، ينفذ الاستدعاء مهمة graphql_enable التي ينفذها المزود في معاملة واحدة: تثبيت الامتداد، وإنشاء وظيفة graphql() في مخططك، ومنح أدوار التطبيق. إذا فشلت إحدى الخطوات، فسيتم إلغاء كل شيء — ولن يتم تثبيت الغلاف في منتصف الطريق أبدًا، ولن ينتقل graphql_enabled إلا إلى true بعد النجاح الكامل.

إنه يعمل على مجموعة Postgres المشتركة وعلى مثيل CNPG مخصص لكل مشروع - صورتان مختلفتان لـ Postgres، ولكن نفس آلية الامتداد. في المثيلات المخصصة، يتم تثبيت الامتداد عبر البيان التعريفي لمشغل CNPG بدلاً من SQL المباشر - وهو تصحيح حديث. يتم تشغيل مجموعة مخصصة دون وصول المستخدم المتميز للتطبيق، ويتطلب pg_graphql هذا الامتياز على وجه التحديد لـ CREATE EXTENSION.

من الاستوديو، يمر نفس التدفق عبر علامة التبويب "تكوين الجدول". هناك زر ينشط الامتداد على مستوى المشروع - نفس استدعاء HTTP كما هو مذكور أعلاه، مع الاستقصاء حتى التقارب. يقوم عنصر التحكم الثاني بعد ذلك بتعيين توجيه @graphql لكل جدول، لتنشيط أو عدم تنشيط totalCount وحقول التجميع في مجموعة GraphQL الخاصة به، دون مغادرة المحرر.

عرض أمر واحد: التنشيط ← وظيفة التوفير مترابطة (غير فعالة، لا يمكن تشغيلها إذا كانت بالفعل في حالة طيران) ← معاملة DDL (تمديد، وظيفة مجمعة، منح) ← وضع علامة graphql_enabled فقط بعد النجاح الكامل ← الطلبات الممكنة عبر /rpc/graphql.

الوظيفة التي تم تعيينها بواسطة Aurabase هي SECURITY INVOKER — السلوك الافتراضي لـ Postgres، والذي تم شرحه بحيث لا يغيره عامل إعادة البناء المستقبلي عن طريق الصدفة. يتم تشغيله بامتيازات المتصل الفعلي (aura_anonأو aura_authenticated أو aura_service_role، اعتمادًا على مطالبة JWT)، لذلك تنطبق سياسات RLS تمامًا كما هو الحال مع طلب REST.

في Hasura، تختلف البنية حسب البناء: يقوم المحرك بتحويل كل استعلام GraphQL إلى استعلام SQL مقيد بقواعد الأذونات الخاصة بـ Hasura. يتم تعريف هذه القواعد لكل دور ولكل جدول في الطبقة الخاصة به - وهو نظام موازٍ لـ Postgres RLS، وليس تفويضًا إليه. مكانان لتدقيق قواعد الوصول، بدلاً من مكان واحد فقط.

يظل الاستبطان ({ __schema { ... } }) معطلاً بشكل افتراضي في كل مشروع Aurabase - وهو وضع يتوافق مع بقية النظام الأساسي. يمكن تنشيطه عن طريق المخطط عبر COMMENT ON SCHEMA إذا كانت أداة مثل Apollo Studio أو graphql-codegen بحاجة إليه.

بمجرد graphql_enabled إلى true، لن يظهر أي مسار /graphql مخصص على البوابة. يمر الطلب عبر وكيل RPC العام، تمامًا مثل أي وظيفة Postgres يتم استدعاؤها من SDK.

curl -X POST "$AURA_URL/v1/db/$PROJECT_ID/rpc/graphql" \
  -H "apikey: $AURA_ANON_KEY" -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { postsCollection(first: 10, filter: { published: { eq: true } }) { edges { node { id title created_at } } } }"}'

تتبع الاستجابة مواصفات GraphQL — { data, errors } — بدون تغليف Aurabase إضافي: تكتشف البوابة أن RPC المستهدف هو graphql ولا تعيد تغليفه، على عكس RPC العادي. يستهلك عميل GraphQL القياسي (Apollo، urql، graphql-request) الإخراج كما هو.

يتم تعيين إعدادين افتراضيًا عند التنشيط، عبر توجيه @graphql على الرسم التخطيطي: max_rows: 1000 و inflect_names: true. pg_graphql أحرف استهلالية افتراضيًا عند 10000 صف لكل مجموعة - بدون first:، يمكن لجدول كبير أن يشبع الذاكرة. inflect_names يعطي أسماء أنواع قابلة للقراءة بدلاً من حالة الثعبان الأولية لجداول SQL.

أن يتم توثيقها بدلاً من إخفائها، بروح هذه المدونة.

• لا توجد اشتراكات GraphQL أصلية. يغطي pg_graphql الاستعلامات والطفرات، وليس في الوقت الفعلي subscriptions - وهذا تقييد للامتداد نفسه، وليس إغفال Aurabase. توجد Aurabase في الوقت الفعلي، ولكن من خلال قناة منفصلة (postgres_changes)، وليس جسر اشتراكات GraphQL.
• لا توجد إجراءات تصريحية على غرار Hasura. ليس لنموذج "خطاف الويب للأعمال المتصل بطفرة GraphQL" مكافئ مباشر - في Aurabase، يمر هذا المنطق من خلال وظيفة Postgres أو وظيفة Edge، وليس من خلال تكوين GraphQL مخصص.
• محجوز لمحرك Postgres. لا يمكن لمشروع MongoDB تمكين هذا - ولا يوجد حل بديل.

جميع الخيارات الثلاثة مشروعة - يعتمد الاختيار الصحيح على ما لديك بالفعل وما تريد تجنبه.

• pg_graphql على Aurabase — إذا كانت قاعدة بيانات وسياسات RLS الخاصة بك موجودة بالفعل على Aurabase وتريد طريقة ثانية للاستعلام عنها بدون خدمات إضافية للمراقبة.
• Hasura — إذا قمت بتوحيد مصادر بيانات متعددة (وليس Postgres فقط) خلف مخطط GraphQL واحد، أو إذا كان PromptQL ونهج وكيل الذكاء الاصطناعي الخاص به يناسبان خريطة الطريق الخاصة بك.
• PostGraphile v5 — إذا كنت تريد تحكمًا دقيقًا في المخطط الذي تم إنشاؤه عبر نظام المكونات الإضافية الخاص به، وكنت تقوم بالفعل بتشغيل خادم Node.js لدمجه فيه.

للحصول على صياغة استعلام كاملة - عوامل التصفية حسب نوع العمود، وفرز orderBy، وترقيم الصفحات حسب المؤشر، وطفرات insertInto<Table>Collection - راجع الوثائق الرسمية pg_graphql. توضح وثائق Aurabase GraphQL أدناه أيضًا تفاصيل الدورة الكاملة.