حدود Cloudflare D1 المجانية: متى تتوقف الاستعلامات؟

أصبحت حدود Cloudflare D1 المجانية عاملاً حاسماً في قرار تشغيل الخدمة في بيئة الإنتاج اعتباراً من 1 سبتمبر 2026. فمتى استهلك الحساب 5 ملايين صف مقروء أو 100,000 صف مكتوب خلال يوم واحد، قد تتوقف استعلامات D1 حتى منتصف الليل بتوقيت UTC.

غيّرت Cloudflare آلية التعطل، لا الحصة المجانية

كانت حدود الاستخدام المجاني قائمة بالفعل. الجديد هو ما يحدث عند بلوغها.

على Workers Free، يؤدي تجاوز أي من الحدين اليوميين الآن إلى رفض D1 للاستعلامات عبر Workers Binding API وREST API معاً. وتوثّق Cloudflare رسائل منفصلة لحدّي القراءة والكتابة، كما توضّح أن الاستعلامات تُستأنف عند إعادة ضبط الحصة في 00:00 UTC. تظل البيانات المخزنة سليمة، لكن تطبيقك قد يعجز مع ذلك عن قراءتها أو تعديلها.

وهنا تكمن المسألة كلها: رقم استخدام مرن تحوّل إلى حد صارم لتوافر الخدمة.

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

لا يتأثر Workers Paid بهذا التوقف اليومي. وقد لا يحتاج نموذج أولي يظل بعيداً بأمان عن الحدين إلى الترقية اليوم. أما المنتج الفعلي الذي يعتمد على D1، فعليه الآن التعامل مع الخطة Free مثل أي مورد آخر له نقطة توقف.

حدود Cloudflare D1 المجانية تُقاس بالصفوف المفحوصة

حصة القراءة ليست 5 ملايين استدعاء API ولا 5 ملايين سجل تعيده الاستعلامات، بل 5 ملايين صف تفحصه قاعدة البيانات أثناء تنفيذها.

لنفترض أن مرشحاً يعيد عميلاً واحداً، لكن الجدول يفتقر إلى فهرس مفيد. قد تضطر D1 إلى فحص جدول يضم 5,000 صف للعثور على ذلك السجل. نفّذ الاستعلام 1,000 مرة، وستكون قد استهلكت حصة القراءة اليومية كاملة، أي 5 ملايين صف. النتيجة بدت صغيرة، أما العمل الذي جرى خلفها فلم يكن كذلك.

الكتابة أوضح حساباً. تحتسب عمليات INSERT وUPDATE وDELETE بحسب عدد الصفوف التي تغيّرها. فإذا أُضيفت 10 صفوف، تُحسب 10 صفوف مكتوبة. وقد تستهلك عمليات المخطط مثل CREATE وALTER وDROP مزيجاً من القراءات والكتابات أيضاً.

حجم الصف لا يغيّر هذا المقياس. فالصف بحجم 1 KB والصف بحجم 100 KB يُحسب كل منهما صفاً واحداً. ما يرفع عدد القراءات هو شكل الاستعلام.

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

يقدم دليل الفهارس من Cloudflare اختباراً واضحاً: أضف EXPLAIN QUERY PLAN قبل الاستعلام المكلف. ظهور SCAN في الخطة يعني أن الجدول يُفحص، بينما يعني SEARCH ... USING INDEX أن فهرساً قيد الاستخدام. وبعد إضافة الفهرس، شغّل PRAGMA optimize كي يعمل مخطط الاستعلام بإحصاءات حديثة.

تغيّرت المعادلة التجارية

لا تزال Workers Free تكلف $0. لكن ما تغيّر هو حجم الضرر المحتمل: ستبقى فاتورة قاعدة البيانات القصوى صفراً، بينما قد تتوقف القاعدة عن خدمة التطبيق حتى نهاية اليوم بتوقيت UTC.

تبدأ Workers Paid من $5 لكل حساب شهرياً. وهي تستبدل التوقف اليومي الصارم باستخدام شهري مشمول وتسعير للاستهلاك الزائد.

الفارق بين Free وPaid أكبر مما يبدو للوهلة الأولى. فالوصول إلى سقف القراءة في Free طوال ثلاثين يوماً يعادل 150 مليون صف فقط، أي 0.6% من 25 مليار قراءة مشمولة في Paid. والوصول إلى سقف الكتابة في Free طوال ثلاثين يوماً يعادل 3 ملايين صف، أي 6% من 50 مليون كتابة مشمولة.

لذلك، لا يكون أول قرار مدفوع في كثير من التطبيقات الصغيرة متعلقاً بتكلفة الاستهلاك الزائد، بل بإنفاق $5 لضمان التوافر. ولا تزال طلبات Workers وCPU وتخزين D1 فوق 5 GB وأي منتجات أخرى من Cloudflare خاضعة لمقاييسها الخاصة؛ لذا فإن $5 هي الحد الأدنى، لا وعداً بأن تكلفة الحساب كاملة ستساوي $5 تماماً. ويوضح استعراض تسعير Cloudflare الأوسع مواضع الفصل بين الحساب والمنتجات.

لا تفرض D1 رسوماً على نقل البيانات أو معدل النقل. هذا لا يخفف أثر التعطل في الخطة Free؛ بل يعني فقط أن الخروج ليس رقماً إضافياً في هذا القرار.

أربعة فرق، وأربع خطوات عملية

مؤسس منفرد يدير SaaS فعلياً

إذا كانت عملية تسجيل الدخول أو حالة الفوترة أو لوحة تحكم العميل تقرأ من D1، أصبحت الخطة Free تنطوي على خطر توقف الخدمة في بيئة الإنتاج. ابدأ بتحديد أكثر الأيام العادية ازدحاماً، ثم أصلح أي فحص كامل للجداول. وإذا ظل التطبيق يقترب من الحد، فإن الحد الأدنى البالغ $5 أقل كلفة من التخطيط لساعات مجهولة بلا وصول إلى قاعدة البيانات.

العائد ليس سعة أكبر لقاعدة البيانات بمعناها المجرد، بل إخراج منتصف الليل بتوقيت UTC من خطة التعافي من الحوادث.

وكالة تدير عدة قواعد بيانات في حساب واحد

صياغة الحد مرتبطة بالحساب. لذلك، ينبغي للمسؤول في الوكالة حصر كل قاعدة بيانات D1 في حساب Cloudflare، لا فحص مشروع عميل واحد ثم اعتبار الحساب بأكمله آمناً.

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

مهندس خلفية يتتبع القراءات المكلفة

المهمة هي تحديد أشكال الاستعلامات، لا حذف البيانات عشوائياً. تعيد D1 القيمتين rows_read وrows_written داخل كائن meta لكل استعلام، وتكشف هذه الأرقام الكلفة الدقيقة لعملية تنفيذ واحدة.

تتيح Cloudflare أيضاً رؤى الاستعلامات عبر Wrangler وGraphQL Analytics API. رتّب النتائج بحسب القراءات للعثور على عمليات الفحص المتكررة، وافحص الخطة، ثم أضف الفهرس المحدد المطلوب وأعد القياس. والنتيجة استهلاك أقل للحصة، وغالباً زمن استجابة أقل أيضاً، من التغيير نفسه.

مسؤول عمليات يدير عمليات الاستيراد أو المزامنة

قد تستهلك مزامنة مجمعة 100,000 كتابة قبل أن تحصل حركة العملاء على فرصة لاستخدام قاعدة البيانات. وزّع مهمة غير عاجلة على فترات إعادة الضبط، أو انقل الحساب إلى Paid قبل استيراد بيانات الإنتاج.

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

ضع ميزانية للحد قبل وصول التنبيه

هذه سياسة أولية قابلة للتطبيق، وهي قاعدة تشغيلية لا تفرضها Cloudflare: خصص للإنتاج 80% من الحصة المنشورة للخطة Free. بذلك يصبح سقف التشغيل اليومي 4 ملايين قراءة و80,000 كتابة، مع إبقاء 1 مليون قراءة و20,000 كتابة احتياطياً للطفرات وتأخر القياس.

1. 1

   قس استهلاك يوم فعلي

   افتح Cloudflare، وانتقل إلى D1، وحدد كل قاعدة بيانات، ثم افتح Metrics. يعرض الإعداد الافتراضي آخر 24 ساعة. اجمع من السجل ما يكفي لرؤية أيام العمل العادية، وعمليات الإطلاق والاستيراد، وطفرات الزيارات. تحتفظ D1 بهذه المقاييس لمدة 31 يوماً.

2. 2

   اعثر على الاستعلام الذي يستهلك الصفوف

   استخدم قيمتي meta.rows_read وmeta.rows_written لكل استعلام أثناء اختبار المسارات المهمة. واستعن برؤى الاستعلامات لترتيب العبارات المتكررة أو المكلفة. شغّل EXPLAIN QUERY PLAN على أسوأ استعلام قراءة، وعالج الفحص الكامل قبل اعتبار ترقية الخطة الحل الوحيد.

3. 3

   أرسل التنبيه قبل الحد الصارم

   استخدم GraphQL Analytics API، الذي يقرأ مجموعات البيانات نفسها المستخدمة في لوحة التحكم، لإجراء فحص مجدول على مستوى الحساب. نبّه المسؤول عند 4 ملايين قراءة أو 80,000 كتابة. تظل رسالة Cloudflare عند بلوغ الحد مفيدة لتأكيد الحادث، لكنها يجب ألا تكون أول إشارة إلى مشكلة في الإنتاج.

4. 4

   حدّد استجابة التعطل الآن

   قرر مسبقاً ما الذي يعيده Worker إذا أطلقت D1 خطأ متعلقاً بالحد. قد تظل القراءة المخزنة مؤقتاً مفيدة إن لم تنفذ استعلاماً آخر على D1. أما مسار الكتابة فيحتاج إلى استجابة واضحة بعدم التوافر أو إلى طابور مصمم بصورة مستقلة. لا تدخل في حلقة إعادة محاولات أمام حصة لن تتعافى قبل منتصف الليل بتوقيت UTC أو إجراء ترقية.

تذكر وثائق مقاييس D1 أن rowsRead وrowsWritten هما حقلا GraphQL، وتؤكد أن لوحة التحكم تستخدم بيانات التحليلات نفسها. وهذا يمنح الفريق الصغير مساراً يدوياً اليوم، وآخر قابلاً للأتمتة عندما تصبح قاعدة البيانات مهمة بما يكفي لاستدعاء المسؤول المناوب.

ما لا يعالجه الحل بصراحة

الفهرس ليس مجانياً. فهو يستهلك مساحة تخزين ويضيف كتابات عند تغيير القيم المفهرسة. أضف الفهارس التي تزيل عمليات الفحص المكلفة، ثم قس التوازن الجديد. وقد يتخذ حساب يقترب أصلاً من حد 100,000 كتابة قراراً أسوأ إذا فهرس الأعمدة بلا تمييز.

خطة Paid ليست غير محدودة أيضاً. فهي تشمل 25 مليار قراءة و50 مليون كتابة كل شهر، ثم تحاسب على الاستهلاك الزائد بالأسعار المنشورة. تزيل الترقية التوقف اليومي في Free، عادة خلال دقائق، لكنها لا تلغي الحاجة إلى مراقبة الاستعلامات السيئة أو تقدير بقية فاتورة Workers. وينبغي الاحتفاظ بـصفحة تسعير D1 الحالية ضمن دليل التشغيل بوصفها مرجع الأرقام.

هناك تفصيل واحد في تسلسل المصادر يستحق المعرفة. فقد ذكرت ملاحظة إصدار لـD1 في يناير 2025 أن تطبيق الحد سيبدأ في 10 فبراير 2025. أما سجل التغييرات الأحدث والخاص بهذا الحدث فيقول إنه يبدأ في 1 سبتمبر 2026. اعتمدت الصفحة الأحدث مرجعاً حاكماً لأنها تسمي الإطلاق الحالي مباشرة، وهذا يفسر ظهور تاريخ مختلف في نتيجة بحث أقدم.

وأخيراً، عبارة «البيانات المخزنة لا تتأثر» أضيق معنى من القول إن «المنتج بخير». قد تبقى بياناتك آمنة بينما يعيد كل مسار يحتاج إليها خطأً. توافر الخدمة هو الأثر التجاري.

ما الذي ينبغي فعله يوم الاثنين؟

تحرك هذا الأسبوع إذا كان تطبيق يتعامل مع العملاء يعمل على Workers Free وكانت D1 ضمن مسار الطلب. ابدأ بالقياس، وأصلح عمليات الفحص الواضحة، واضبط التنبيه عند 4 ملايين قراءة و80,000 كتابة، وامنح موافقة مسبقة على الانتقال إلى Paid مقابل $5.

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

لا يشملك هذا التوقف اليومي تحديداً إذا كان الحساب مشتركاً بالفعل في Workers Paid أو كان التطبيق لا يستعلم من D1.

خطوة الاثنين بسيطة: افتح تبويب D1 Metrics لكل قاعدة بيانات، وسجّل أعلى يوم للقراءة والكتابة على مستوى الحساب، وحدد الاستعلام المسؤول عن أكبر عملية فحص، وامنح شخصاً واحداً صلاحية الترقية. إذا ظلت ذروة عادية تتجاوز 4 ملايين قراءة أو 80,000 كتابة بعد إصلاح الاستعلام، فانقل الحساب إلى Workers Paid في اليوم نفسه.

إذا أردت تحويل التغيير التالي في المنصة إلى قرار تشغيلي واضح، فاشترك في النشرة البريدية.