إشارة 24 سبتمبر: بيتا 4 والميزات المحذوفة
صدرت بيتا 4 من PostgreSQL 19 في 24 سبتمبر 2026 على postgresql.org/about/news/. يتضمن دورة إصدار PostgreSQL المعتادة 3 إلى 4 نسخ بيتا قبل الإتاحة العامة في أكتوبر؛ إصدار رابعة في سبتمبر يشير إلى أن المشروع لم يصل إلى مستوى الاستقرار المستهدف في موعده.
الجديد اللافت في هذه النسخة بيتا ليس إصلاحاً تقنياً — بل قائمة الحذف. يحصي تحليل نشره فريق هندسة Snowflake 53 ميزة كانت مخططة أصلاً لـPostgreSQL 19 وتم تأجيلها إلى إصدار لاحق. هذا النوع من الحذف الجماعي في مرحلة بيتا نادر في تاريخ المشروع الذي حافظ على جدول زمني سنوي منتظم جداً لعشرين عاماً.
النتيجة المباشرة: الإتاحة العامة لـPostgreSQL 19 متوقعة الآن في أواخر أكتوبر 2026، أي تأخير بعدة أسابيع عن الجدول الأصلي. بالنسبة للأنظمة المستضافة ذاتياً في الإنتاج، هذا التحول ليس تافهاً: فهو يضيق نافذة الاختبار قبل تجميد نهاية العام ويؤخر جدول الترحيل بأكمله.
ما الذي تم حذفه ولماذا يهم
من بين 53 ميزة محذوفة، تستحق ثلاث مجموعات اهتمام المطورين العاملين مع أنظمة تطبيقات حديثة.
الحذوفات التي تؤثر على مطوري التطبيقات
- تحسينات SQL/JSON path — تحسينات التنقل
jsonpathفي مستندات JSON المتداخلة، مستخدمة على نطاق واسع في واجهات REST APIs التي تخزن بيانات شبه منظمة. يعني حذفها أن الاستعلامات التي تعتمد عليها ستضطر للاستمرار باستخدام بدائل أكثر تعقيداً. - استعلامات الرسم البياني SQL (معيار ISO SQL:2016) — دعم استعلامات الرسم البياني وفق معيار ISO SQL:2016، مما كان سيتيح نمذجة العلاقات المعقدة مباشرةً بـSQL القياسي دون إضافات. هذا الحذف مهم للمشاريع الراغبة في الانتقال من حلول NoSQL إلى PostgreSQL.
- تحسينات MERGE المنقولة إلى PG 18 — تحسينات عبارة
MERGEالمخططة لـPG 19 تم تأجيلها. بعضها تم نقله إلى PostgreSQL 18، مما يعزز جاذبية هذا الإصدار بأثر رجعي.
لماذا هذه الحذوفات لا تُبطل PG 19
حذف ميزة في مرحلة بيتا هو علامة نضج، لا فشل. يفضل مشروع PostgreSQL تسليم أقل على تسليم غير مستقر — هذا ما يكسبه سمعته في موثوقية الإنتاج. ستكون الميزات الـ53 المحذوفة مرشحة لـPostgreSQL 20. ما يجب أن يشغل انتباهك هو الجدول الزمني: نافذة الاختبار قبل الإتاحة العامة ضيقة جداً الآن.
التأثير الملموس على كل نظام مستضاف ذاتياً
السؤال العملي ليس «هل PostgreSQL 19 جيد؟» بل «على أي إصدار يعمل نظامي، وهل يغير PG 19 شيئاً في خطة الترحيل؟». الأدوات الأربعة الأكثر انتشاراً على خوادم VPS المستضافة ذاتياً لها متطلبات موثقة تشكّل الإجابة.
n8n يوثق PostgreSQL 14+ كقاعدة بيانات مدعومة. في الإنتاج المستضاف ذاتياً، تعمل معظم حالات n8n على PG 14 أو PG 15 — الانتقال إلى PG 18 قفزة محكومة، لا تتطلب ميزات PG 19.
Supabase يوزع PostgreSQL 15 افتراضياً في صورته المستضافة ذاتياً. المشروع يتبع الإصدارات المستقرة بتأخير تأهيل داخلي لبضعة أسابيع. لن يُدعم PG 19 إلا بعد أشهر من الإتاحة العامة؛ استهداف PG 18 هو المسار المتسق.
Nextcloud 35 يدرج PostgreSQL 15+ في وثائقه الرسمية. لا تتطلب Nextcloud اليوم أي ميزة من PG 19.
Mattermost Team Edition يوثق PostgreSQL 14+ كمتطلب أساسي. الانتقال إلى PG 18 لا يستلزم أي تغيير على مستوى التطبيق.
إصدار PostgreSQL المطلوب حسب التطبيق المستضاف ذاتياً
مرّر الجدول أفقيًا
| التطبيق | الحد الأدنى الموثق لإصدار PG | الإصدار الافتراضي الموزع | متوافق مع PG 18 | يتطلب PG 19 |
|---|---|---|---|---|
| n8n | PG 14+ | PG 14 أو 15 حسب الصورة | نعم (لا تغييرات مطلوبة) | لا |
| Supabase self-hosted | PG 15+ | PG 15 (الصورة الرسمية) | نعم (التأهيل جارٍ) | لا |
| Nextcloud 35 | PG 15+ | PG 15 موصى به | نعم | لا |
| Mattermost Team Edition | PG 14+ | PG 14 أو 15 | نعم | لا |
التوصية: PostgreSQL 18 هو الهدف الانتقالي السليم
وصل PostgreSQL 18 إلى الإتاحة العامة في أبريل 2026. يتمتع بدورة دعم خمس سنوات (حتى 2031) وهو مستقر في الإنتاج منذ عدة أشهر. هذا هو الإصدار الذي يجب على الفرق التي كانت تخطط لـPG 19 استهدافه الآن.
ثلاثة أسباب ملموسة تدعم PG 18 كهدف انتقالي:
1. تحسينات MERGE المقررة لـPG 19 تم نقل بعضها إلى PG 18 — تستفيد منها دون انتظار.
2. الترحيل من PG 17 إلى PG 18 موثق وبدون احتكاك جوهري. التوافق مع الإضافات الشائعة (pgvector وPostGIS وTimescaleDB) مضمون.
3. خمس سنوات دعم من أبريل 2026 — لا ضغط فوري للترقية، ونافذة مريحة لتأهيل PG 19 حين يكون مستقراً فعلاً في الإنتاج.
الاستراتيجية الصحيحة: الترحيل إلى PG 18 الآن، والتخطيط لـPG 19 عام 2027.
دليل الترحيل من PG 16/17 إلى PG 18
يُنجز الترحيل الرئيسي لـPostgreSQL باستخدام pg_upgrade، الأداة القياسية للمشروع. يتطلب إيقاف الخدمة لكنه لا يستلزم إعادة تثبيت كاملة — يُحافظ على الكتالوج والبيانات.
خطوات الترحيل من PG 16 أو PG 17 إلى PG 18
نسخ البيانات احتياطياً قبل أي عملية
الترحيل الرئيسي لا رجعة فيه بدون نسخة احتياطية. أنشئ تفريغاً كاملاً:
pg_dumpall -U postgres > /backup/pg_full_$(date +%Y%m%d).sqlتحقق من أن الملف قابل للقراءة وغير فارغ قبل المتابعة. على VPS، انسخ التفريغ أيضاً إلى تخزين خارجي.
تثبيت PostgreSQL 18 بجانب الإصدار الحالي
على Debian/Ubuntu، يتيح مستودع PGDG تثبيت إصدارات متعددة جنباً إلى جنب:
apt install postgresql-18يتعايش الإصدارانعلى منافذ مختلفة.
pg_upgradeسينجز الترحيل بين الكلاسترين دون تشغيل الإصدار القديم.إيقاف الإصدار القديم وتشغيل pg_upgrade
أوقف الإصدار القديم (PG 16 أو PG 17) بشكل نظيف:
systemctl stop postgresql@17-mainشغّل
pg_upgradeفي وضع الفحص (--check) أولاً:pg_upgrade \ -b /usr/lib/postgresql/17/bin \ -B /usr/lib/postgresql/18/bin \ -d /var/lib/postgresql/17/main \ -D /var/lib/postgresql/18/main \ --checkإذا اجتاز الفحص بدون أخطاء، شغّله مجدداً بدون
--checkلإجراء الترحيل الفعلي.إعادة ضبط المنفذ وإعادة التشغيل
بعد الترحيل، أشر تطبيقك إلى كلاستر PG 18. إذا أبقيت المنفذ 5432، عدّل
/etc/postgresql/18/main/postgresql.conf:port = 5432شغّل نسخة PG 18:
systemctl start postgresql@18-mainتحقق من الإصدار الفعال:
psql -U postgres -c "SELECT version();"التحليل والتنظيف بعد الترحيل
بعد
pg_upgrade، أعد بناء الإحصاءات على جميع قواعد البيانات:vacuumdb --all --analyze-in-stages -U postgresبعد التحقق، يمكنك حذف الكلاستر القديم وحزمه:
/usr/lib/postgresql/17/bin/pg_dropcluster 17 main apt remove postgresql-17
التحقق من إصدار PostgreSQL في الإنتاج
قبل التخطيط لأي شيء، معرفة الإصدار الدقيق في الإنتاج أمر ضروري. تختلف الأوامر بحسب سياق التثبيت.
أوامر تشخيص الإصدار
- عبر psql:
psql -U postgres -c "SELECT version();"— يعرض الإصدار الكامل مع رقم الرقعة. - عبر systemctl:
systemctl status postgresql— يظهر اسم الخدمة الفعّالة التي تحتوي على رقم الإصدار الرئيسي. - عبر Docker:
docker exec <container> psql -U postgres -c "SELECT version();"لنسخة حاوية. - عبر pg_lsclusters (Debian/Ubuntu):
pg_lsclusters— يسرد جميع الكلاسترات المثبتة ومنافذها وحالتها وإصداراتها. - عبر سجلات التطبيق: n8n وSupabase وMattermost تسجّل إصدار PostgreSQL عند بدء التشغيل — تحقق من السجلات إذا لم يكن لديك وصول مباشر للخادم.
التخطيط للترحيل إلى PG 19: الجدول الزمني والاحتياطات
الإتاحة العامة لـPostgreSQL 19 متوقعة أواخر أكتوبر 2026. الجدول الزمني الواقعي لاعتماد الإنتاج في الاستضافة الذاتية يبدو هكذا:
- أواخر أكتوبر 2026: الإتاحة العامة لـPG 19، أولى حزم PGDG متاحة.
- نوفمبر–ديسمبر 2026: فترة يُنصح بتجنب الترحيل فيها — تجميد نهاية العام، فرق ناقصة، مخاطر تشغيلية عالية.
- يناير–فبراير 2027: أول رقعة صيانة لـPG 19. هذه هي الإشارة المعتادة لاعتبار الاختبار على بيئة مرحلية.
- الربع الأول–الثاني 2027: التأهيل على نسخة مرحلية باستخدام تفريغ إنتاج مجهول الهوية، وتحقق من الإضافات واختبارات الأداء.
- الربع الثاني–الثالث 2027: الترحيل إلى الإنتاج للفرق التي أكملت دورة التحقق الكاملة.
ثلاثة احتياطات لا يجب تخطيها أبداً:
1. اختبر أولاً على تفريغ إنتاج مجهول الهوية، لا على بيانات اختبار اصطناعية — الأحجام وأنماط الاستعلام الحقيقية تكشف انحدارات لا تراها الـfixtures.
2. تحقق من توافق كل إضافة قبل الترحيل: pgvector وPostGIS وpg_cron وpg_trgm لكل منها دورة تأهيل خاصة لكل إصدار رئيسي.
3. احتفظ بخطة تراجع موثقة: مع pg_upgrade، التراجع ممكن طالما لم تحذف الكلاستر القديم — وثّق إجراء الاستعادة قبل الترحيل.
إعداد VPS لـ PG 18 باستخدام Docker
إذا كان نظامك يعمل بالفعل على Docker، يمكن الترحيل إلى PG 18 بجانب نسخة الإنتاج دون استخدام pg_upgrade. الصورة الرسمية postgres:18 متاحة على Docker Hub منذ الإتاحة العامة في أبريل 2026.
نشر PG 18 على VPS باستخدام Docker Compose
إنشاء ملف docker-compose.yml لـ PG 18
أنشئ دليلاً مخصصاً وملف الإعداد:
mkdir -p /opt/postgres18 && cd /opt/postgres18محتوى
docker-compose.yml:cat > docker-compose.yml << 'EOF' services: postgres: image: postgres:18 container_name: postgres18 restart: unless-stopped environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} POSTGRES_USER: ${POSTGRES_USER:-postgres} POSTGRES_DB: ${POSTGRES_DB:-app} volumes: - ./data:/var/lib/postgresql/data ports: - "127.0.0.1:5432:5432" EOFأنشئ ملف
.envبقيمك:echo 'POSTGRES_PASSWORD=كلمة_مرور_قوية' > .envاستيراد البيانات من النسخة القديمة
شغّل الحاوية الجديدة:
docker compose up -dاستعد التفريغ من نسختك القديمة (PG 16 أو PG 17):
psql -U postgres -h 127.0.0.1 -p 5432 < /backup/pg_full_$(date +%Y%m%d).sqlتحقق من وجود قواعد البيانات والجداول:
docker exec postgres18 psql -U postgres -lالتحقق والتحويل إلى التطبيق
قبل تحويل التطبيق، تحقق من الإصدار الفعال في الحاوية:
docker exec postgres18 psql -U postgres -c "SELECT version();"حدّث متغير
DATABASE_URL(أوDB_HOST/DB_PORT) في تطبيقك ليشير إلى الحاوية الجديدة. أعد تشغيل التطبيق وتحقق من سجلات بدء التشغيل — n8n وNextcloud وMattermost تسجّل جميعها اتصال PostgreSQL عند التهيئة.
VPS بصلاحيات root يمنحك الهامش الذي الاستضافة المُدارة لا توفره
اختبار PG 18 بجانب نسخة الإنتاج، والتحقق من نظامك على تفريغ مجهول الهوية، والتراجع دون الاعتماد على مزود: هذا ما يتيحه الوصول بصلاحيات root على VPS. الاستضافة المشتركة أو PaaS المُدار يفرض جدول ترقيات المزود — غالباً دون إشعار مسبق بالإصدار المستهدف أو إمكانية الاختبار المسبق.
الخلاصة: تصرف الآن لا بعد إصدار PG 19
تأخير PostgreSQL 19 وحذف 53 ميزة ليسا إشارات إنذار حول جودة المشروع — هذه هي عملية النشر الطبيعية لبرنامج بهذا الحجم. لكنهما يغيران الجدول الزمني للفرق التي كانت تخطط للقفز مباشرة إلى PG 19 قبل نهاية 2026.
nافذة التصرف هي الآن، قبل الإتاحة العامة لـPG 19:
- إذا كنت على PG 15 أو PG 16: خطط للترحيل إلى PG 18. هو الإصدار المستقر، المدعوم 5 سنوات، الذي تغطي ميزاته جميع متطلبات الأنظمة المستضافة ذاتياً الشائعة.
- إذا كنت على PG 17: أنت في وضع جيد. PG 17 مدعوم حتى 2029؛ الترحيل إلى PG 18 يمكن أن ينتظر دورة صيانة هادئة.
- في جميع الحالات: لا تخطط لـPG 19 في الإنتاج قبل الربع الثاني من 2027 — تأهيل الإضافات وأولى نتائج الإنتاج تستلزم أشهراً عدة بعد الإتاحة العامة.
جدول الترحيل يُقرر حين تكون الخيارات مفتوحة، لا حين يُغلق الضغط التشغيلي الأبواب.
