تشغيل منتج على Cloudflare Edge: ما كسبناه، وما تنازلنا عنه

كل قاعدة بيانات D1 نُشغّلها لديها السقف نفسه: 10 GB، صلبة، لكل قاعدة — رقم تُعلنه وثائق Cloudflare نفسها بوضوح ولم يتغيّر في 2025 أو 2026 (opens in new tab). ضربناه مرة في أداة اختبار سجّلت كل جسم طلب HTTP لأسبوع. الكتابة فشلت برسالة SQLITE_FULL مقتضبة. هذه الصفقة التي توقّع عليها حين تبني على طبقة بيانات Cloudflare، وعلى التوازن نعتقد أنها جيدة. هذا المقال جولة صادقة في شحن منظومة Teknora على Workers + Pages + D1 + Workers AI — ومتى نقول للعملاء أن يذهبوا ويُشغّلوا Postgres على Hetzner بدلاً من ذلك.

نُشغّل الموقع التسويقي، والمدونة، ولوحة التحليلات، وchatbot لـteknora.org بالكامل على Cloudflare. ثلاث قواعد بيانات D1 تُربط في الـWorker، زائد Workers AI لاستدلال الدردشة وR2 لأصول الصور. المنظومة كلها تُنشر في نحو أربعين ثانية من git push إلى استجابة مُخزَّنة عالميًا في فرانكفورت.

المنظومة، ولماذا

Next.js 15 App Router، مُجمَّع عبر @opennextjs/cloudflare (opens in new tab)، ومُنشر إلى Workers بربط أصول بنمط Pages. المثابرة ثلاث قواعد D1 عبر Drizzle ORM. الـchatbot يستدعي Workers AI مباشرة عبر الربط. كل شيء موصول في wrangler.toml.

شيئان دفعانا إلى هنا على إجابة Vercel-زائد-Neon الافتراضية. أولاً، زمن الاستجابة في ألمانيا: متوسط TTFB من ميونخ هبط من نحو 180 ms على Vercel إلى نحو 60 ms على Workers، بمساعدة توجيه "shard and conquer" من Cloudflare الذي رفع معدل الطلبات الدافئة إلى 99.99٪ (opens in new tab). ثانيًا، التكلفة: خطة Workers Paid تبدأ بـ5 دولارات شهريًا مع 10 ملايين طلب، وWorkers AI يعمل على الغلاف نفسه بـ0.011 دولار لكل 1,000 Neuron مع 10,000 Neuron يوميًا مجانًا (opens in new tab)، والخروج صفر.

ما يعمل بجمال

بيئات المعاينة مجانية وفورية. كل فرع يحصل على URL معاينة بربط D1 خاص (preview_database_id) وKV. ينقر أصحاب المصلحة رابطًا من هاتف؛ يرسم في 40 ms من لندن.

النشرات سريعة بما يكفي لتكون مملة. بناء إنتاج كامل بخط أنابيب MDX وبناء قاعدة المعرفة الأولي لـchatbot نحو 40 ثانية. الإرجاعات عبر لوحة المعلومات فورية تقريبًا.

نموذج الربط ممتاز بهدوء. بدلاً من سلاسل DATABASE_URL، تحصل على ارتباطات مكتوبة الأنواع: env.TRACKING_DB، وenv.AI. لا بيانات اعتماد في الشيفرة، لا إدارة اتصالات. ربط Workers AI لطيف: await env.AI.run("@cf/meta/llama-3.2-3b-instruct", { messages }) مع تسعير لكل نموذج بالرموز (opens in new tab) أرخص بمراتب عدة من OpenAI في أحجام النماذج الصغيرة.

التكلفة على مقياس SMB خطأ تقريب. لأعباء عمل Mittelstand — بضع مئات الآلاف من الطلبات يوميًا، وبضعة GB من البيانات، وchatbot يتعامل مع مئة محادثة — الفاتورة في الضوضاء.

ما هو صعب حقيقة

D1 هو SQLite تحت الغطاء — جميل البساطة للقراءة، مؤلم للكتابات المتزامنة.

D1 كاتب واحد، وستشعر بذلك. يستطيع الـWorker فتح حتى 6 اتصالات متزامنة (opens in new tab)، لكن قاعدة البيانات تُسلسل الكتابات. النسخ المتماثل القرائي العالمي عبر Sessions API وصل إلى بيتا عامة في أبريل 2025 (opens in new tab) ويساعد كثيرًا. لأعباء العمل التي توزّع الكتابات — تحليلات على كل عرض صفحة، أو مستهلكي إدراج مجمّع — تصطدم بالمنافسة بسرعة. حلنا الاحتياطي على TRACKING_DB كان تجميع الكتابات خلف Queue. يعمل، لكنه ليس نمطًا تحتاجه على Postgres.

سقف الـ10 GB حقيقي، والتقسيم عليك. يمكنك تزويد حتى 50,000 قاعدة لكل حساب على خطة Paid (opens in new tab) والتقسيم بالمستأجر؛ كتابات عامة وثّقت الانتقال من 10 GB إلى مئات الـGB عبر تقسيم يدوي (opens in new tab). لكن "التقسيم اليدوي" يعني أنك تكتب طبقة التوجيه، والاستعلامات عبر الشرائح، والترحيلات بنفسك — مصدر حقيقي للأخطاء، خاصة للتقارير التي تريد رؤية كل المستأجرين مرة واحدة.

ترحيلات المخطط مقبولة، لا ممتازة. wrangler d1 migrations apply يُشغّل ملفات SQL المرتّبة بشكل idempotent مع جدول تتبّع، ويتراجع إلى الحالة الناجحة السابقة عند الخطأ (opens in new tab). ما يغيب مقارنة بأدوات Postgres: لا EXPLAIN للترحيل، ولا DDL عبر الإنترنت، ولا طريقة مريحة للتطبيق عبر عشرات قواعد البيانات المُقسّمة للمستأجرين دون كتابة السكريبت بنفسك. مجتمع Drizzle كان يحل الجزء الأخير بسكريبتات مخصصة (opens in new tab)، وطلب ميزة wrangler لتطبيق متعدد القواعد (opens in new tab) لا يزال مفتوحًا.

N+1 في سياق الحافة أسوأ مما تذكر. كل استعلام قفزة منفصلة عبر وقت تشغيل Worker إلى شريحة قاعدة البيانات. أمسكنا N+1 خاصتنا التي نقلت صفحة من 80 ms إلى 600 ms. جمّع أو IN (...) كل شيء؛ عامل Promise.all على ربط D1 كرائحة للتحقيق.

قصة Next.js على Cloudflare

كانت فوضى، الآن جيدة فعلاً. @cloudflare/next-on-pages كان المُحوّل الأصلي والتهم جزءًا كبيرًا من سطح الميزات. في 2024 بدّلت Cloudflare إلى @opennextjs/cloudflare (opens in new tab)، الذي يُشغّل وقت تشغيل Node من Next.js داخل Worker؛ وصل 1.0 في 2025 وهو الآن المسار الموصى به (opens in new tab).

ما تحصل عليه اليوم: App Router، وRoute Handlers، والمسارات الديناميكية، وSSG، وSSR، وISR، والـmiddleware القياسي، وتحسين الصور، وPartial Prerendering، ودالة after()، والتخزين المركّب، وأصول Turbopack. ما لا تحصل عليه، حتى أبريل 2026: Node Middleware من 15.2 غير مدعوم بعد (opens in new tab)، ووقت تشغيل Edge من Next.js كذلك، وسقف حجم Worker هو 3 MiB مضغوط على Free و10 MiB على Paid (opens in new tab). لدغة محددة: next-mdx-remote أنتج حزمة لم يستطع prerender RSC تسلسلها؛ رحّلنا إلى next-mdx-remote-client. نصف يوم من المهام الجانبية — النوع من الشيء الذي تأكله حين تُشغّل المُحوّل بدلاً من تكامل Vercel الأصلي.

إقامة البيانات الأوروبية عمليًا

هنا انتقلت Cloudflare من "ربما" إلى "قابل للاستخدام" لعملاء Mittelstand في DACH خلال 2025. اعتبارًا من نوفمبر 2025، D1 يدعم تثبيت الاختصاص وقت إنشاء قاعدة البيانات (opens in new tab) مع eu وfedramp. تُنشئ بـnpx wrangler d1 create db-name --jurisdiction=eu وقاعدة البيانات — بما فيها أي نسخ متماثلة قرائية، مقيّدة بالاختصاص نفسه (opens in new tab) — تعمل فقط داخل الاتحاد الأوروبي. الاختصاص ثابت.

تحذيران للمُدقّق. الـWorker الذي يستعلم قاعدة مُثبّتة بالاختصاص لا يزال يستطيع العمل في أي مكان عالميًا — الاختصاص يُقيّد مكان وجود البيانات، لا الحوسبة. احضر جملة للـDPIA. وR2 له قصة اختصاص خاصة (EU يعمل)، KV لا تُقدّم بعد تثبيتًا صلبًا، وتنفيذ Workers AI يعتمد على النموذج. للإقامة الصارمة — رعاية صحية، سجلات قانونية — اقرأ وثائق Data Localization Suite (opens in new tab) وخصص ميزانية لـEnterprise. لموقع تسويقي، وسجل chatbot، ومُتتبّع حملة، الافتراضيات جيدة.

متى نقول للعملاء أن يغادروا

OLTP ثقيل مع منافسة كتابة. آلاف الكتابات في الثانية على مجموعة بيانات منطقية واحدة باتساق قوي؟ Postgres على Hetzner مع نسخة متماثلة قرائية، أو Neon (opens in new tab) لـergonomics ذات طابع serverless، سيكون أقل ألمًا. الكاتب الواحد على D1 جيد لمعظم SaaS؛ ليس لواجهة POS تحجز المخزون مقابل صناديق متزامنة.

المهام طويلة التشغيل. Workers Paid يُشغّل الآن حتى 5 دقائق من وقت CPU لكل طلب و15 دقيقة على Cron Triggers أو Queue Consumers (opens in new tab)، قفزة كبيرة من 30 ثانية الافتراضية القديمة. ما لا يُغطيه: ETL ليلي يعالج 50 مليون صف، وتحويل فيديو، وخط أنابيب PDF لـ2000 صفحة. لتلك نُشغّل Hetzner مع Coolify — خط حقيقي في اقتصاديات سحابة SMB (opens in new tab) بـ5–10 يورو شهريًا.

ميزات Postgres المحددة التي نستخدمها فعلاً. أمن مستوى الصف، وLISTEN/NOTIFY، والفهارس الجزئية، وjsonb مع GIN، والنسخ المتماثل المنطقي، ومُحفّزات PL/pgSQL. محاكاتها على D1 تتجاوز فائدة الحافة. رحّلنا مشروعًا صغيرًا واحدًا بعيدًا عن D1 لهذا السبب بالضبط.

استعلامات التقارير والتحليل. D1 هو SQLite OLTP، لا مستودع. حد وقت الاستعلام 30 ثانية وكلفة مسح الصفوف يعنيان أن pivot عبر كل الحسابات سينتهي بمهلة. لذلك نُزامن إلى ClickHouse (opens in new tab)، أو DuckDB على تخزين الكائنات، أو Analytics Engine الخاصة بـCloudflare.

قائمة مراجعة قصيرة للقرار

نستخدم قائمة مراجعة من صفحة واحدة عند تحديد نطاق مشاريع العملاء:

• هل البيانات لكل مستأجر على الأرجح ستبقى تحت 10 GB لخمس سنوات؟ إن لا، خطط للتقسيم من اليوم الأول أو اختر Postgres.
• هل الكتابات متقطعة-ومتزامنة؟ ضع Queue أمامها.
• تحتاج طبقة تقارير فوق البيانات التشغيلية؟ خطط مسار المزامنة قبل اختيار المخزن الأساسي.
• هل يذكر العقد إقامة البيانات؟ اختصاص EU على D1 يُغطي كثيرًا؛ Hetzner في Nürnberg يُغطي الباقي.
• مهمة طويلة التشغيل في نموذج المجال؟ لا تجعل الـWorker يمتلكها — Cron + Queue + عامل Hetzner، أو Workflow.
• هل الفريق طليق بالفعل في Postgres؟ التقنية المملة التي يستطيع الفريق تشغيلها الساعة الثانية صباحًا تغلب التقنية الذكية التي لا يستطيعون.

من آخر ستة ارتباطات Mittelstand، أربعة عملت بشكل جميل على Cloudflare، واحد عمل على Hetzner لأن عبء العمل كان بشكل ETL، وواحد عمل هجينًا — طبقة ويب على الحافة، Postgres مُدار بـHetzner خلف نفق خاص لنواة OLTP. الثلاثة كانت أرخص وأسرع للشحن من إجابة الانعكاس "Vercel زائد AWS RDS". الحافة ليست رصاصة فضية؛ إنها موقف معماري محدد، والشيء الأكثر قيمة الذي يجلبه مهندس أول هو معرفة أي جانب من الخط أنت قبل توقيع العقد.

قراءات إضافية

• Cloudflare D1 platform limits (opens in new tab) — القائمة المعتمدة؛ تصفّحها قبل أي تصميم قائم على D1.
• Cloudflare Workers platform limits (opens in new tab) — مستويات وقت CPU، وعدد subrequests، والذاكرة.
• D1 read replication deep-dive (opens in new tab) — كيف يحافظ Sessions API على الاتساق التسلسلي عبر النسخ المتماثلة.
• @opennextjs/cloudflare documentation (opens in new tab) — ميزات Next.js المدعومة والتحذيرات المعروفة.
• D1 jurisdictions changelog (Nov 2025) (opens in new tab) — تثبيت بيانات EU وFedRAMP.
• "Shard and Conquer" cold-start post (opens in new tab) — قصة معدل الدافئة 99.99٪.