Postgres 16 مقابل 17 مقابل 18: المكاسب المهمة

لا تتميز الإصدارات الثلاثة برقم أداء عام واحد. يصحح كل منها نقطة معينة من البنية، مع جمهور مختلف في كل مرة: جداول كبيرة لـ Postgres 17، وتخزين عالي الكمون لـ Postgres 18. يلخص الجدول أدناه الحقائق التي يمكن التحقق منها، وكلها مؤرخة، قبل الخوض في تفاصيل كل مشروع.

المصادر: ملاحظات الإصدار الرسمية لمشروع PostgreSQL (postgresql.org)، مع الإشارة المرجعية إلى التحليلات المنشورة بواسطة Microsoft Tech Community وCrunchy Data بعد كل إصدار رئيسي. تم الوصول إليه في 24 أغسطس 2026.

قبل Postgres 17، قام VACUUM بتخزين قائمة المجموعات الميتة لتنظيفها في مصفوفة بسيطة بحجم maintenance_work_mem. لم تكن المشكلة في سرعة الحساب، بل في البنية نفسها: استقر هذا الجدول عند حوالي 1 جيجابايت، بغض النظر عن مقدار التهيئة بعد ذلك. على طاولة تحتوي على أكثر من 178 مليون صف ميت، كان على VACUUM أن يتكرر في عدة تمريرات، كل منها يعيد قراءة الفهارس بالكامل.

يستبدل Postgres 17 هذه المصفوفة ببنية تسمى TidStore، وهي شجرة جذرية قابلة للتكيف تعمل على ضغط المساحة اللازمة لتخزين معرفات المجموعة بشكل كبير. تشير ملاحظات الإصدار الرسمية للمشروع إلى انخفاض في الذاكرة المستخدمة بواسطة VACUUM بما يصل إلى 20 مرة في بعض الحالات، بدون السقف الاصطناعي المرتبط بالهيكل القديم. المصدر: ملاحظات الإصدار الرسمية لـ PostgreSQL 17، postgresql.org، 26 سبتمبر 2024. نشر كل من Microsoft Tech Community وCrunchy Data تحليلاً فنيًا لهذا التغيير بعد وقت قصير من الإصدار. يؤكد كلاهما الاهتمام الملموس بالجداول المكونة من عدة مئات من ملايين الصفوف، مع معدل حذف أو تحديث مرتفع.

يستفيد هذا المشروع بشكل أساسي من سيناريو محدد: جدول كبير ذو معدل حذف أو تحديث مرتفع. تم تشغيل VACUUM مسبقًا في عدة تمريرات بسبب نقص الذاكرة المتوفرة. على طاولة صغيرة، أو على حمل قراءة في الغالب، يظل المكسب هامشيًا، أو حتى غير مرئي.

يتطرق مشروع Postgres 17 الثاني إلى نقطة أكثر سرية: حساب لقطات المعاملات. يحتاج كل استعلام إلى معرفة المعاملات الأخرى الجارية لفرض قواعد رؤية MVCC الخاصة بـ Postgres. على جهاز يحتوي على عدد كبير من النوى والاتصالات النشطة، أدى هذا الحساب إلى تنافس على بنية داخلية مشتركة. وهذا هو عنق الزجاجة الذي تم توثيقه لفترة طويلة من قبل المساهمين في المشروع.

Postgres 17 يقلل من هذا الخلاف. يتم قياس التأثير بشكل أساسي على المثيلات عالية التزامن، مع العديد من الاتصالات النشطة المتزامنة على أجهزة متعددة النواة. في حالة الحمل المتزامن المنخفض، يظل الفرق مع Postgres 16 هامشيًا: إنه مشروع قابلية التوسع، وليس تقليل زمن الوصول لكل طلب معزول.

لا يحل هذا المكسب محل مجمع الاتصال، بل يقلل ببساطة من تكلفته الداخلية. إذا كان عدد الاتصالات النشطة هو بالفعل عنق الزجاجة لديك، فإن الإصدار الرئيسي يأخذ مقعدًا خلفيًا. دليل ضبط max_connections ومقارنة وضع المعاملات PgBouncer استكشف هذا الموضوع بمزيد من التفاصيل.

يعالج Postgres 18، الذي تم إصداره في نهاية سبتمبر 2025، مشكلة أكثر هيكلية. حتى ذلك الحين، كانت كل قراءة قرص Postgres تمنع العملية التي طلبت ذلك. يسمح النظام الفرعي الجديد للإدخال والإخراج غير المتزامن (AIO) للعملية ببدء عمليات قراءة متعددة بالتوازي ومواصلة العمل أثناء اكتمالها، بدلاً من انتظار كل واحدة بالتسلسل.

تتحكم المعلمة io_method في هذا السلوك: worker (العمليات المخصصة للإدخال/الإخراج، افتراضيًا) أو io_uring على Linux، عندما تم تجميع Postgres بهذا الدعم. تعد عمليات الفحص التسلسلي، ومسح كومة الصور النقطية، وVACUUM أول المستفيدين، خاصة على وحدات التخزين ذات زمن الاستجابة العالي: أقراص الشبكة، ووحدات التخزين السحابية، بدلاً من NVMe المحلي.

قامت PlanetScale، التي تقدم عرض Postgres المُدار، بنشر مقارنات Postgres 17 مقابل 18 الخاصة بها والتي تركز على تغيير الإدخال/الإخراج هذا. هذه هي قياساتهم على البنية التحتية الخاصة بهم، وليست الأرقام التي قمنا بإعادة إنتاجها بشكل مستقل هنا. اعتبرها إشارة إلى أن الموضوع يستحق الاختبار على حملك الفعلي، وليس كنسبة مئوية عالمية.

AIO المعمم لـ Postgres 18 هو استمرار لمشروع بدأ في Postgres 17، وليس تغييرًا معزولًا. لقد قدم الإصدار 17 بالفعل واجهة الإدخال/الإخراج المتدفقة، ولكنه يقتصر على التحليل وعمليات الفحص التسلسلي. يقوم Postgres 18 بتوسيع هذا المنطق نفسه ليشمل نطاقًا أوسع من العمليات، بما في ذلك فحص VACUUM ومسح كومة الصور النقطية. لذلك يتم قراءة الإصدارين على أنهما تقدم، وليس كرهانين منفصلين على الإدخال/الإخراج.

هناك ثلاثة تغييرات أخرى في Postgres 18 تستحق المراقبة، حتى لو لم تعالج الأداء الأولي بشكل مباشر.

يسمح بتخطي الفحص على فهرس B-tree متعدد الأعمدة لـ Postgres باستخدام فهرس مركب حتى عندما لا يتم تصفية الاستعلام على العمود الرئيسي الخاص به. قبل Postgres 18، كان هذا السيناريو يتطلب غالبًا فحصًا كاملاً للجدول، أو إنشاء فهرس مخصص إضافي.

تصبح الأعمدة الافتراضية التي تم إنشاؤها (GENERATED ALWAYS AS (...) VIRTUAL) هي السلوك الافتراضي عندما لا يتم تحديد STORED. يتم حساب العمود الافتراضي عند القراءة بدلاً من كتابته على القرص، مما يقلل من الكمية المكتوبة في كل مرة يتم فيها إدراج الصف المصدر أو تحديثه.

يضيف Postgres 18 أخيرًا دعمًا لـ OAuth 2.0 من ناحية المصادقة (RFC 8628، تدفق الجهاز)، إلى جانب الآليات الموجودة مثل SCRAM أو الشهادات أو LDAP. نقطة ذات صلة لأي مؤسسة تقوم بالفعل بمركزية هوياتها عبر موفر OAuth/OIDC خارجي.

في Aurabase، تعمل قاعدة بيانات المستأجر حاليًا في Postgres 16.15، وليس 17. يمكن التحقق من ذلك مباشرة في المستودع: تبدأ صورة CNPG المرجعية (docker/Postgres.CNPG.Dockerfile) من ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm، مثبتة بواسطة الملخص، نفس الإصدار الرئيسي مثل الطبقة المشتركة (docker/Postgres.Dockerfile). تم التحقق منه في 24 أغسطس 2026.

يوثق الكود أيضًا السبب. يوضح تعليق التصحيح في k8s_tenant.rs أن الإجراء الاحتياطي السابق أشار عن طريق الخطأ إلى postgresql:17.2. السبب الذي تم تقديمه في ذلك الوقت، وهو أن الصورة القياسية لا تتضمن pgvector، تبين أنه غير صحيح عند التحقق. تحتوي كلتا الصورتين على pgvector: 0.8.0 على 17.2، 0.8.5 على 16-standard-bookworm مقاسة على مجموعة الأسطول.

الخطر الحقيقي، الموثق في التعليق نفسه، موجود في مكان آخر: يحظر CloudNativePG أي تخفيض كبير للإصدار بمجرد إنشاء المجموعة. الأسطول الذي تم توفيره عن طريق الخطأ في Postgres 17 سيكون لا رجعة فيه، في حين أن كل ما تم التحقق من صحته من البداية إلى النهاية في Aurabase كان في Postgres 16.

// يتم الاحتفاظ بالإصدار الرئيسي إذا لم يتم تعريف TENANT_POSTGRES_IMAGE
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

هذا ليس حكمًا على Postgres 17 في حد ذاته. إنها سياسة الحكمة التشغيلية: لا تقم بتحويل أسطول الإنتاج إلى إصدار رئيسي حتى يتم اتباع التحقق الشامل. ينطبق نفس المنطق على أي فريق يدير Postgres عبر CloudNativePG أو مشغل Kubernetes المكافئ. لا يقتصر السؤال على مكاسب الأداء المتوقعة فحسب، بل يتعلق أيضًا بمسار العودة إذا حدث خطأ ما.

هل يجب عليك الهجرة إلى Postgres 17 أو 18 الآن؟

ثلاثة معايير تجعل من الممكن اتخاذ القرار دون انتظار رقم عالمي. أولاً، حجم ومعدل التحول لأكبر جداولك: إذا كان VACUUM قيد التشغيل بالفعل في عدة تمريرات، فإن موقع عمل ذاكرة Postgres 17 ينطبق مباشرة على حالتك. بعد ذلك، التخزين الخاص بك: على SSD المحلي بزمن انتقال منخفض، يوفر الإدخال/الإخراج غير المتزامن لـ Postgres 18 أقل من حجم الشبكة. أخيرًا، طريق العودة: بالنسبة للمشغل الذي يحظر الرجوع إلى إصدار أقدم، فإن الاختبار أولاً على بيئة يمكن التخلص منها ليس إجراءً احتياطيًا اختياريًا.

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

لا يقتصر الاختيار بين Postgres 16 و17 و18 على الإصدار "الأسرع" فقط. يعمل Postgres 17 على إصلاح مشكلة VACUUM الهيكلية الحقيقية على الجداول الكبيرة ويقلل التنافس عند التزامن العالي. يذهب Postgres 18 إلى أبعد من ذلك من خلال الإدخال/الإخراج غير المتزامن، وهو تغيير معماري يتطلب اختبار التحميل والتخزين الفعلي قبل تعميمه.

إن المعيار الذي يتم نسيانه في أغلب الأحيان ليس الأداء، بل قابلية التراجع. في مشغل مثل CloudNativePG، لا يتم التراجع عن ترقية الإصدار الرئيسي بعد حدوثها. قبل تبديل أسطول الإنتاج، فإن السؤال الحقيقي ليس فقط المكاسب المتوقعة، بل هو أيضًا مسار العودة في حالة فشل الاختبار. إذا كنت تستعد لترقية هذا الإصدار، فإن قائمة التحقق من ضبط Postgres في الإنتاج في الإنتاج توضح تفاصيل الإعدادات التي سيتم إعادة التحقق منها بعد تغيير كبير في الإصدار.