في التاسع من يوليو 2026، أعلن مالكولم ماتيس — الرئيس التنفيذي السابق لشركة Heap ومستخدم قديم لـ Postgres — عن شيء كان سيبدو كسخرية قبل ثمانية عشر شهرًا: إعادة كتابة كاملة لـ PostgreSQL بلغة Rust، ولّدها في معظمها ثمانية وكلاء برمجيات ذكاء اصطناعي، تجتاز جميع 46,066 استعلامًا في مجموعة الانحدار الخاصة بـ PostgreSQL 18.3.
ليس مجموعة فرعية. ليس "معظمها". المجموعة بأكملها، دون فشل واحد.
يُعرف المشروع بـ pgrust، وهو مرخّص بموجب AGPL-3.0، وقد غدا النقطة الأكثر وضوحًا حتى الآن في نقاش تخوضه المطوّرون طوال العام: هل تستطيع وكلاء الذكاء الاصطناعي فعلًا إنجاز أعمال الأنظمة الجادة، أم أنها تُنتج كودًا يبدو معقولًا لكنه ينهار عند مواجهة الواقع؟
الجواب الصادق، كالمعتاد، يقع في المنطقة البينية — والتفاصيل في غاية الأهمية.
ما الذي بُني فعلًا
الأرقام تستحق أن تُذكر بصراحة:
| المقياس | القيمة |
|---|---|
| أسطر Rust المُولَّدة | أكثر من 450,000 |
| وكلاء الذكاء الاصطناعي المتوازيون | 8 (حسابات Codex مدفوعة) |
| أداة التنسيق | Conductor، 10–20 جلسة متوازية |
| التكلفة الشهرية للوكلاء | نحو 1,600 دولار |
| استعلامات الانحدار المجتازة | 46,066 / 46,066 |
| الوقت حتى أول بناء ناجح | نحو ثلاثة أشهر |
الصف الأخير يستحق الاهتمام. تُمثّل PostgreSQL ما يقارب ثلاثة عقود من الهندسة المتراكمة. استطاع فريق صغير مسلّح بأسطول من الوكلاء إعادة إنتاج سلوكها الخارجي في لغة مختلفة خلال ربع واحد فقط، بأقل من تكلفة مهندس مبتدئ شهريًا.
الإصدار v0.1 ليس لعبة. إنه يتحدث بروتوكول Postgres الأصلي، لذا تتصل به psql وبرامج تشغيل العملاء القياسية دون تعديل. يعمل مباشرة من دليل بيانات PostgreSQL 18.3 الحالي — دون تفريغ، دون ترحيل، دون تحويل. يُشغّل مخطط استعلام حقيقي: يعمل EXPLAIN ANALYZE ويتخذ قرارات فهرس-مقابل-مسح-تسلسلي حقيقية لا مزيّفة.
يمكنك تجربته في نحو ثلاثين ثانية:
docker pull malisper/pgrust:v0.1
docker run -d --name pgrust-demo -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1
docker exec -it pgrust-demo psql -U postgres -h 127.0.0.1ثمة أيضًا عرض تجريبي عبر المتصفح بتقنية WebAssembly على pgrust.com إن كنت تفضّل تجنب تنزيل الصورة.
الرهان المعماري
هنا تكفّ pgrust عن كونها تمرينًا في الترجمة لتصبح حجة هندسية حقيقية.
تستخدم PostgreSQL نموذج عملية لكل اتصال. كل اتصال عميل يستنسخ عملية نظام جديدة. هذا هو السبب في أن PostgreSQL اشتُهرت بالنهم على الذاكرة عند ارتفاع عدد الاتصالات، ولهذا يجلس PgBouncer أو ما يماثله خلف كل نشر إنتاجي تقريبًا. يعود هذا التصميم إلى حقبة كانت فيها الخيوط البرمجية غير موثوقة وعزل العمليات هو الخيار السليم.
الإصدار v0.1 يحتفظ بهذا النموذج — بشكل منطقي، إذ كان الهدف أولًا هو التوافق. لكن فرع التطوير غير المُطلق يُحوّل إلى خيط لكل اتصال: تعمل قاعدة البيانات كعملية واحدة، وتصبح الاتصالات خيوطًا خفيفة الوزن، وتُشارك الذاكرة بدلًا من تكرارها. هذا يُتيح ذاكرات مخبأة مشتركة عبر الاتصالات ويُقلّل الحاجة إلى التجميع الخارجي.
النتائج المُعلنة عن هذا الفرع:
- أسرع بنسبة 50% في الإنتاجية التعاملية على Percona-TPCC
- أسرع بنحو 300 مرة على أحمال العمل التحليلية
- أسرع بـ 10 أضعاف في عمليات التعبير المنتظم
- لا يزال أبطأ بمرتين من ClickHouse على ClickBench
اعتبر كل هذه الأرقام إرشادية. تأتي من قاعدة كود غير مُطلقة ولم تُعاد إنتاجها باستقلالية. ماتيس نفسه يصف v0.1 بحذر بأنها ليست جاهزة للإنتاج ولا مُحسَّنة للأداء.
رقم الـ 300 مرة في التحليل أقل سحرًا مما يبدو. محرك التنفيذ الصفّي في PostgreSQL لم يُصمَّم أبدًا لمسح الأحمال التحليلية، وتجاوزه على هذا المحور فوز معروف ومفهوم. نتيجة ClickBench — لا تزال بنصف سرعة ClickHouse — هي الرقم الأكثر إفادةً، لأنها تُظهر pgrust في موضع معقول مقارنةً بمحرك عمودي متخصص لا في أرض الأوهام.
ما الذي لا يعمل
النظام البيئي للامتدادات هو الجدار.
pgvector وTimescaleDB وPostGIS — لا شيء منها يعمل. ولقطاع ضخم من نشرات PostgreSQL الفعلية في 2026، هذا بالضبط سبب اختيار PostgreSQL أصلًا. PostgreSQL بلا pgvector ليست بديلًا مباشرًا لفريق يبني توليدًا معززًا بالاسترجاع؛ إنها منتج مختلف يتحدث نفس البروتوكول.
هذه ليست فجوة عرضية. امتدادات PostgreSQL تُرتبط بواجهات برمجة C الداخلية، وسياقات الذاكرة، وجداول مؤشرات الدوال التي ليس لها مكافئ طبيعي في Rust. دعمها يعني إما إعادة تنفيذ كل امتداد بلغة Rust أو بناء طبقة توافق FFI تُعيد الكثير من عدم الأمان الذي اعتمدت Rust لتجنّبه. لا خيار من الاثنين مشروع عطلة نهاية أسبوع.
يحمل نموذج الخيط لكل اتصال أيضًا تكلفة حقيقية لا يُظهرها جدول المعايير. مع عزل العمليات، يقتل خطأ تجزئة في خادم خلفي اتصالًا واحدًا. مع نموذج ذاكرة مشتركة، يمكن لفساد ذاكرة في خيط واحد إسقاط كل الاتصالات على المثيل. ضمانات Rust تُسهم كثيرًا هنا — لكن كتل unsafe موجودة في أي قاعدة بيانات تتعامل مع صفحات خام، وقاعدة الكود هذه تضم 450,000 سطر تحتاج تدقيقًا.
ما الذي يجب أن يُغيّر تفكيرك فعلًا
من المغري تصنيف هذا تحت "عرض تجريبي مثير، أتجاهله حتى v2." هذا سيكون خطأ، لكن ردّ الفعل المعاكس سيكون خطأً أيضًا.
الادعاء المهم فعلًا ليس أن الذكاء الاصطناعي كتب قاعدة بيانات. إنه أن مجموعة اختبارات شاملة تبيّن أنها مواصفة كافية لآلة كي تُعيد تنفيذ نظام ما. مجموعة انحدار PostgreSQL هي الجنون المتراكم لثلاثين عامًا من مشرفين يكتبون كل حالة حافة طالت أيّهم. هذا المجمع، كما اتضح، كثيف بما يكفي لتوجيه أسطول من الوكلاء نحو التكافؤ السلوكي.
لهذا تداعية مباشرة على قاعدة كودك الخاصة، وليست التداعية التي يصل إليها معظم الناس أولًا. ليست "يمكننا الآن إعادة كتابة نظامنا القديم." إنها: جودة مجموعة اختباراتك تُحدد الآن ما إذا كانت الهجرة بمساعدة الذكاء الاصطناعي متاحة لك أصلًا. لا يمكن إعادة كتابة نظام باختبارات ضعيفة بأمان عبر وكلاء، لأن لا شيء يُقيّد المخرجات. أما نظام يمتلك مجموعة سلوكية شاملة فيمكن ذلك. غدا تغطية الاختبارات قدرة هجرة بهدوء، لا مجرد تكتيك لمنع العيوب.
الثقل المقابل بالغ الأهمية أيضًا. اجتياز 46,066 استعلام انحدار لا يعني الصواب. تفشل قواعد البيانات الإنتاجية بطرق لا تستطيع مجموعات الاختبارات هيكليًا التقاطها: تأخر النسخ المتماثل تحت التقسيم، فساد WAL بعد انقطاع الكهرباء، انحدارات المخطط تظهر فقط عند توزيع إحصاءات جداول بعينها، أنماط تنافس الأقفال تظهر عند ألف كاتب متزامن. موثوقية PostgreSQL تأتي من ثلاثة عقود من هذا التعرض، لا من ملفات اختباراتها. إعادة إنتاج الاختبارات تُعيد إنتاج المواصفة، لا التصلّب.
المشككون محقون في هذا، ومحقون بطريقة لا تُقلّل من الإنجاز.
هل يجب أن تفعل شيئًا حيال ذلك؟
لأحمال العمل الإنتاجية، الجواب لا، وسيظل كذلك لبعض الوقت. لا أحد يجب أن يفكر في pgrust لأي بيانات حقيقية في 2026.
لكن ثمة ثلاثة أشياء تستحق الفعل:
شغّل صورة Docker. أشِر إليها على نسخة من دليل بيانات حقيقي وشغّل حِمل استعلاماتك الفعلية ضدها. ثلاثون دقيقة من التجربة المباشرة أقيم من أي مقال، بما فيه هذا، لمعايرة مدى تقدم هذه التقنية.
دقّق مجموعة اختباراتك كأصل هجرة. اطرح سؤالًا محددًا: لو سلّمت مجموعة اختباراتك وحدها لمهندس كفء لم يرَ كودك، أيستطيع إعادة تنفيذ النظام؟ أينما كان الجواب لا، فذلك بالضبط حيث التحديث بمساعدة الذكاء الاصطناعي غير متاح لك — وهو حيث يستحق سدّ الفجوة على أي حال.
أعِد معايرة تقديرات النطاق بحذر. الحدس القديم بأن إعادة الكتابة على مستوى الأنظمة التزام متعدد السنوات والفرق لم يعد موثوقًا لجزء توليد الكود. لا يزال موثوقًا تمامًا للتحقق والتصلّب والثقة الإنتاجية — وهو حيث، كما تُبيّن pgrust، سكنت الغالبية العظمى من التكلفة الحقيقية دائمًا.
التوليف غير المريح
كلتا القراءتين الشائعتين لـ pgrust خاطئتان.
"يستطيع الذكاء الاصطناعي الآن إعادة كتابة أي شيء" خاطئة، لأن فجوة الامتدادات والمعايير غير المُتحقق منها والتصلّب الغائب ليست مهام ثانوية — إنها الجزء الأكبر من العمل المتبقي، والجزء الصعب.
"هذا مجرد عرض تجريبي بلا جوهر" خاطئة أيضًا، لأن 46,066 استعلام انحدار مجتاز على قاعدة عمرها ثلاثون عامًا لم يكن شيئًا يمكن للصناعة إنتاجه بهذه التكلفة قبل ستة أشهر، والادعاء بغير ذلك إخفاق في الملاحظة.
ما تغيّر فعلًا هو النسبة. كتابة الكود لم تعد الجزء المكلف في الهجرة الكبيرة. معرفة ما إذا كان الكود صحيحًا لا تزال كذلك — والفرق الذين استثمروا في معرفة ذلك، عبر الاختبارات وقابلية الملاحظة وانضباط المواصفات، هم من اكتسبوا للتو قدرة جديدة حقًا.
في نقطة، هذا هو العدسة التي نطبقها على أعمال التحديث: نادرًا ما تكون الهجرة محجوبة بحجم الكود. تكون محجوبة بعدم القدرة على إثبات أن النظام الجديد يتصرف كالقديم. pgrust هي الإثبات الأوضح حتى الآن على ما يُصبح ممكنًا حين تتوفر تلك البيّنة — وعلى كم العمل المتبقي بعدها.
قراءات ذات صلة: