Prisma توقف خدمة Accelerate المستضافة في 1 ديسمبر 2026، والبديل يعيد الـ pooling دون الـ caching

تنص صفحة الانتقال في توثيق Prisma على أن الاتصال المستضاف بخدمة Accelerate سيتوقف في 1 ديسمبر 2026. وظهر هذا التاريخ أول مرة في سجل تغييرات الشركة بتاريخ 2 أكتوبر 2026. والروابط المتأثرة هي التي تبدأ بـ prisma+postgres://accelerate.prisma-data.net، أما الروابط المحلية مثل prisma+postgres://localhost:51213 فلا يشملها القرار.

يبدو الأمر للوهلة الأولى تغييرًا في رابط الاتصال، لكنه أكبر من ذلك. فقد كانت Accelerate تؤدي وظيفتين معًا. الأولى هي الـ connection pooling، أي الاحتفاظ بمجموعة من الاتصالات المفتوحة بقاعدة البيانات وتوزيعها على الطلبات، بدل أن يفتح كل طلب اتصالًا جديدًا. والثانية هي الـ query caching، أي حفظ نتائج الاستعلامات المتكررة وإعادتها مباشرة دون أن يصل الطلب إلى قاعدة البيانات أصلًا.

والبديل الذي تقترحه Prisma يعيد الوظيفة الأولى فقط. فقاعدة Prisma Postgres نفسها تتضمن pooling، ويمكن الاتصال بها عبر pooled TCP أو عبر الـ serverless driver الخاص بالشركة. أما الـ caching فليس له بديل داخل المنتج.

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

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

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