Cloudflare Workers Python: اتصال مباشر بقواعد البيانات الحالية
تتيح Hyperdrive لتطبيقات Cloudflare Workers Python الاتصال مباشرة بقواعد PostgreSQL وMySQL الحالية. تعرّف إلى أثر ذلك في بنية التطبيق وتكلفته الشهرية.

في 16 سبتمبر 2026، أتاحت Cloudflare لتطبيقات Cloudflare Workers Python الاتصال مباشرة بقواعد PostgreSQL وMySQL عبر Hyperdrive. وإذا كان Worker لديك يحتاج إلى خدمة HTTP منفصلة لمجرد الوصول إلى قاعدة بيانات قائمة، فقد يصبح بالإمكان الاستغناء عنها الآن، بما يغيّر بنية التطبيق وفاتورته الشهرية معًا.
كيف تصل Cloudflare Workers Python إلى قاعدة بيانات قائمة؟
القيمة الحقيقية لهذا الإصدار تكمن فيما لم تعد مضطرًا إلى نقله.
Hyperdrive طبقة اتصال مُدارة بين Cloudflare Worker وقاعدة PostgreSQL أو MySQL موجودة بالفعل. فهي ليست قاعدة بيانات جديدة، ولا تنسخ سجلاتك إلى Cloudflare. يفتح كود Python اتصال TCP باستخدام برنامج تشغيل اعتيادي لقاعدة البيانات وبيانات اتصال يوفرها ربط Hyperdrive، بينما تتولى Hyperdrive إدارة مجمع الاتصالات طويلة الأمد مع قاعدة البيانات خلفها.
وهذا يغيّر الحل الالتفافي الشائع. فقد كان Worker بلغة Python، عندما يتعذر عليه الوصول مباشرة إلى قاعدة البيانات، يستدعي واجهة API صغيرة أو خادمًا لا يفعل سوى تنفيذ أوامر SQL. وكان المسار على النحو التالي:
سابقًا: Worker بلغة Python → وسيط قاعدة البيانات → PostgreSQL أو MySQL
الآن: Worker بلغة Python → Hyperdrive → PostgreSQL أو MySQL
تنفّذ Cloudflare إعداد الاتصال بالقرب من Worker، وتُبقي الاتصالات المجمعة قريبة من قاعدة البيانات الأصلية. ويحصي دليل Hyperdrive سبع جولات ذهاب وإياب في الإعداد التقليدي قبل الاستعلام الأول: واحدة لاتصال TCP، وثلاث لـ TLS، وثلاث لمصادقة قاعدة البيانات. وتحول إعادة استخدام المجمع دون تكرار هذه التهيئة كاملة مع كل تشغيل قصير الأجل لـ Worker.

المسار المدعوم محدد بوضوح. تحتاج Python Workers إلى تاريخ توافق 2026-09-08 أو أحدث، ولا تزال الميزة تجريبية. اختبرت Cloudflare برامج التشغيل asyncpg وpg8000 وpsycopg مع PostgreSQL، إلى جانب aiomysql وpymysql مع MySQL. والبرنامجان الموصى بهما هما asyncpg وaiomysql.
تقول Cloudflare إن برامج تشغيل TCP أخرى قد تعمل، لكن ذلك لا يعني ضمان عمل كل حزمة أو ORM أو تطبيق قائم. توافق قاعدة البيانات يوصلك إلى البوابة الأولى فحسب، ولا يضمن اجتياز عملية الانتقال كاملة.
بند التكلفة الذي تغيّر
يتحقق أوضح وفر في التكلفة عندما يكون تطبيق Python يعمل بالفعل على Workers، بينما تدفع مقابل وسيط لا لشيء سوى تمكين Worker من الوصول إلى قاعدة البيانات.
الحسبة بسيطة:
التكلفة الشهرية الحالية = قاعدة البيانات + Worker + مضيف الوسيط
التكلفة الشهرية المحتملة = قاعدة البيانات + Worker
لن تتغير فاتورة قاعدة البيانات. ولا تُضاف رسوم منفصلة لقاء تجميع الاتصالات والتخزين المؤقت للاستعلامات في Hyperdrive ضمن Workers Paid، كما لا تفرض Hyperdrive رسومًا على نقل البيانات الصادرة. وإذا كان الحساب أصلًا ضمن الاستخدام المشمول في Workers، فستكون الزيادة لدى Cloudflare لهذا المسار $0. ويظل الوفر النقدي المحتمل هو فاتورة استضافة الوسيط التي تختفي فعلًا.
تدخل الصيانة في الحسبة نفسها. فقد تعني إزالة الوسيط أيضًا الاستغناء عن عملية نشر واحدة، وفحص سلامة واحد، ومجموعة أسرار واحدة، وتدفق سجلات واحد، ونقطة فشل واحدة. لا تضع قيمة مالية لهذا العمل قبل معرفة من يتولاه ووتيرة تسببه في المشكلات.
للحساب المدفوع الجديد، تبدأ Workers Paid من $5 لكل حساب شهريًا. وتشمل 10 ملايين طلب و30 مليون مللي ثانية من وقت CPU كل شهر. وتبلغ تكلفة الاستخدام الزائد $0.30 لكل مليون طلب إضافي و$0.02 لكل مليون مللي ثانية إضافية من وقت CPU. أما استعلامات قاعدة البيانات عبر Hyperdrive فهي مدرجة على أنها غير محدودة في هذه الخطة.
يمكن استخدام الخطة المجانية لإثبات مفهوم صغير. فهي تشمل 100,000 طلب Worker يوميًا و100,000 استعلام قاعدة بيانات عبر Hyperdrive يوميًا، مع 10 مللي ثوانٍ من وقت CPU لكل استدعاء. وهذان عدّادان منفصلان؛ فالطلب الواحد الذي ينفذ عدة عبارات SQL قد يستهلك عدة استعلامات لقاعدة البيانات.
من يستطيع الاستفادة من ذلك غدًا؟
مؤسس منفرد لديه خدمة FastAPI
لنفترض أن مؤسسًا يدير FastAPI Worker أمام قاعدة PostgreSQL مُدارة، إلى جانب حاوية صغيرة تستقبل طلبات HTTP وتنفذ أوامر SQL. إذا كانت هذه الحاوية لا تحتوي على أي منطق أعمال، فيمكن لاختبار باستخدام asyncpg أن يبيّن ما إذا كانت Hyperdrive قادرة على استبدالها.
المكسب هنا ليس قاعدة بيانات جديدة، بل الاحتفاظ بالمخطط والنسخ الاحتياطية والمزوّد الحالي مع حذف خدمة لم يكن لها دور سوى تكييف الاتصال. على المؤسس نقل مسار واحد أولًا، ثم مقارنة نتيجته وزمن استجابته، وأخيرًا إزالة الوسيط بعد تطابق السلوك في بيئة الإنتاج.
وكالة صغيرة تدير قواعد MySQL لعملائها
قد تدير وكالة صغيرة عدة واجهات API محدودة بلغة Python، تتصل كل منها بقاعدة MySQL تخص أحد العملاء. ويتيح المسار الجديد للوكالة اختبار aiomysql أو pymysql داخل Worker بدلًا من نشر وكيل لقاعدة البيانات إلى جانب كل تطبيق مؤهل.
المكسب هو اتساق التشغيل. تستطيع الوكالة اعتماد مسار نشر واحد لـ Worker وإعداد Hyperdrive واحد لكل قاعدة بيانات. أما إذا كان الوسيط ينفّذ تفويض المستأجرين، أو تحويل المخطط، أو التدقيق، أو أي مهمة تتجاوز تمرير الاستعلامات، فيجب الإبقاء عليه.
فريق منصة ينقل نقطة نهاية واحدة كثيفة القراءة
لا يحتاج فريق المنصة إلى نقل الواجهة الخلفية بأكملها. يمكنه نقل نقطة نهاية عامة كثيفة القراءة ومبنية بلغة Python إلى Workers، مع إبقاء قاعدة البيانات الإقليمية واستخدام Hyperdrive لتجميع الاتصالات عند المصدر.
وهنا أيضًا ينبغي اتخاذ قرار صريح بشأن التخزين المؤقت. تخزّن Hyperdrive عمليات القراءة المؤهلة مؤقتًا لمدة 60 ثانية افتراضيًا، وقد تعرض نتيجة قديمة لمدة 15 ثانية إضافية أثناء إعادة التحقق منها. قد يناسب ذلك قراءة كتالوج عام أو محتوى، لكن المصادقة والأذونات وحالة الفوترة والقراءة التي تلي الكتابة مباشرة ينبغي أن تستخدم إعداد Hyperdrive منفصلًا مع تعطيل التخزين المؤقت.
تظل مقارنة Django مع FastAPI السابقة مفيدة عند اختيار إطار العمل. يغيّر هذا الإصدار جانبًا واحدًا من القرار: أصبح الإبقاء على PostgreSQL أو MySQL مسارًا موثقًا لـ Python Worker، لكنه لا يمنح بقية تطبيق Django أو FastAPI شهادة توافق.
أنشئ أصغر اختبار اتصال آمن
استخدم قاعدة MySQL غير إنتاجية ومستخدم اختبار محدود الصلاحيات. الهدف هو إثبات مسار الاتصال عبر SELECT 1، لا إجراء بروفة انتقال كاملة على بيانات العملاء.
أنشئ إعداد Hyperdrive مع تعطيل التخزين المؤقت، كي يقيس الاختبار الأول جولة جديدة إلى قاعدة البيانات:
npx wrangler hyperdrive create python-db-test --connection-string="mysql://user:password@HOSTNAME_OR_IP_ADDRESS:PORT/database_name" --caching-disabledانسخ معرّف الإعداد من Wrangler إلى wrangler.toml. التاريخ أدناه أحدث من الحد الأدنى المطلوب 2026-09-08:
name = "python-hyperdrive"
main = "src/main.py"
compatibility_date = "2026-09-16"
compatibility_flags = ["python_workers"]
[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<HYPERDRIVE_CONFIG_ID>"أضف برنامج التشغيل إلى pyproject.toml:
[project]
dependencies = [
"aiomysql",
]ثم استخدم اختبار الاتصال الذي وثقته Cloudflare في src/main.py:
import aiomysql
from workers import Response, WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
hd = self.env.HYPERDRIVE
connection = await aiomysql.connect(
host=hd.host,
port=int(hd.port),
user=hd.user,
password=hd.password,
db=hd.database,
ssl=None,
)
try:
cursor = await connection.cursor()
await cursor.execute("SELECT 1")
result = await cursor.fetchone()
return Response.json({"result": result[0]})
finally:
connection.close()انشره باستخدام أمر Python Workers الموثق:
uv run pywrangler deployالسطر الذي يبدو خاطئًا غالبًا هو ssl=None. فهذا اتصال برنامج التشغيل من Worker إلى Hyperdrive في مثال Cloudflare. ومع ذلك، يظل TLS مطلوبًا لاتصال Hyperdrive بقاعدة البيانات الأصلية، ولا تُدعم اتصالات المصدر غير الآمنة بالنص الصريح.
الوسيط اختياري، لكنه لم يصبح قديمًا تلقائيًا
يغيّر هذا الإطلاق مسار الاتصال، لكنه لا يحوّل Python Workers إلى خادم CPython بلا قيود.
يشمل دعم حزم Python الحزم المكتوبة بالكامل بلغة Python، وحزم wheel المبنية باستخدام PyEmscripten، والحزم المضمّنة مع Pyodide. ولا تزال Cloudflare تصف دعم حزم WebAssembly بأنه في مرحلة مبكرة، لذلك قد توقف تبعية مفقودة عملية الانتقال. وتدعم وثائق برامج التشغيل وORM حاليًا SQLAlchemy المتزامن فقط. أما SQLAlchemy غير المتزامن فغير مدعوم لأن بيئة Workers تفتقر إلى دعم greenlet.
لبروتوكول قاعدة البيانات حدوده أيضًا. تدعم Hyperdrive إصدارات PostgreSQL من 9.0 حتى 17.x وإصدارات MySQL من 5.7 حتى 8.x، إضافة إلى MariaDB. ولا تدعم SQL Server أو MongoDB. كذلك لا تتوفر أقفال PostgreSQL الإرشادية ولا LISTEN أو NOTIFY، كما لا تتوفر استعلامات MySQL متعددة العبارات ولا العبارات المحضّرة على مستوى البروتوكول. ويطبّق حد أقصى لمدة الاستعلام قدره 60 ثانية في الخطتين المجانية والمدفوعة.
يغيّر التجميع افتراضات الجلسة أيضًا. تستخدم Hyperdrive تجميع المعاملات، ما يعيد الاتصال الأصلي إلى المجمع عند انتهاء المعاملة. لذلك يحتاج الكود الذي يتوقع استمرار حالة الجلسة عبر المعاملات إلى مراجعة. وقد تستنفد المعاملات الطويلة المجمع أيضًا، فتُلغي مكسب التزامن.
ما الذي ينبغي فعله يوم الاثنين؟
لا تنقل التطبيق يوم الاثنين. أثبت أولًا ما إذا كان هناك ما يبرر بقاء وسيط مخصص لقاعدة البيانات وحدها.
اختر مسارًا يمكن التخلص منه
أنشئ قاعدة بيانات غير إنتاجية أو نسخة متماثلة مع مستخدم محدود الصلاحيات. اختر مسارًا واحدًا يقرأ سجلًا غير حساس ولا يعتمد على حالة الجلسة أو الأقفال أو الحصول على أحدث قيمة بعد الكتابة.
نفّذ اختبار اتصال سريعًا
انشر Worker الصغير أعلاه وتأكد من نجاح
SELECT 1عبر Hyperdrive. سجّل معدل أخطاء Worker، ووقت CPU، والوقت المنقضي، وعدد اتصالات قاعدة البيانات.اختبر برنامج التشغيل والاستعلام الفعليين
استبدل استعلام الاختبار ببرنامج التشغيل الفعلي للمسار واستعلام نموذجي واحد. قارن البيانات المعادة وسلوك المعاملة وإعداد التخزين المؤقت واستخدام المجمع بالوسيط الحالي.
احسب قيمة الحذف
دوّن فاتورة استضافة الوسيط الشهرية والساعات المستغرقة في نشره وتصحيحه ومراقبته واستعادته. اطرح أي استخدام إضافي لـ Workers والعمل المستمر المطلوب لـ Hyperdrive. لا تحذف الوسيط إلا عندما تؤيد الحسبة واختبار التوافق ذلك معًا.
تحرّك هذا الأسبوع إذا كان الوسيط موجودًا فقط للوصول إلى قاعدة البيانات، وكان التطبيق يستخدم PostgreSQL أو MySQL، وكان برنامج تشغيل مختبر يغطي المسار. انتظر إذا كنت تعتمد على SQLAlchemy غير المتزامن، أو حزمة غير متاحة، أو سلوك SQL غير مدعوم، أو اتساق صارم للقراءة بعد الكتابة لم تفصله بعد. ولن يؤثر فيك هذا التغيير إذا كان التطبيق سيبقى على خادمه الحالي، أو كان الوسيط يحمل منطق أعمال لا تستبدله Hyperdrive.
للحصول على قرار عملي ليوم الاثنين مع كل تغيير جديد في المنصات، اشترك في النشرة البريدية.
- آخر تحديث
- 16 سبتمبر 2026
- التصنيف
- Explained







