SQLite الموزّعة على الحافة: Turso و libSQL في 2026

طوال عقود، كانت SQLite قاعدة بيانات تُضمَّن داخل التطبيق، ولم تكن يومًا قاعدة بيانات تُشغّل منتجًا عالميًا. هذه الفرضية انتهت. في عام 2026، أصبحت SQLite الموزّعة بهدوء معيار قواعد البيانات على الحافة، والأسماء التي تقود هذا التحول هي Turso و libSQL و Cloudflare D1 و Fly.io LiteFS.

النتيجة هي خطّ أداء جديد: زمن استجابة القراءات ينخفض من 30 إلى 80 ميلي ثانية على Postgres المركزي إلى أقل من 10 ميلي ثانية، وإلى ميكروثوانٍ للنسخ المحلية بالكامل. بالنسبة للفرق التي تشحن منتجات عالمية، هذا تحوّل معماري يحدث مرة كل عقد.

لماذا فازت SQLite الموزّعة على الحافة

تبدأ القصة بإحباط. SQLite هي قاعدة البيانات الأكثر انتشارًا على الأرض، بمليارات التثبيتات وتكلفة تشغيل تكاد تكون معدومة، ومحرّك استعلامات صُقل على مدى خمسة وعشرين عامًا. لكنها لم تُصمَّم أبدًا للكتابة المتزامنة أو النسخ المتماثل أو النشر متعدد المناطق. لسنوات، كان هذا يعني أن الأنظمة الإنتاجية مضطرة للجوء إلى Postgres أو MySQL لحظة تجاوزها لعقدة واحدة.

ثم قرّرت مجموعة صغيرة من المشاريع إصلاح ذلك:

• libSQL — تفرّع من SQLite، أُنشئ لأن SQLite مفتوحة المصدر لكنها غير مفتوحة للمساهمات. هي جاهزة للإنتاج ومتوافقة بالكامل مع الإصدارات السابقة، وتضيف قدرات لن يقبلها المشروع الأصلي أبدًا.
• Turso Database — إعادة كتابة كاملة لـ SQLite بلغة Rust، صُمّمت من اليوم الأول للكتابة المتزامنة والإدخال/الإخراج غير المتزامن وأعلى كثافة قواعد بيانات في الصناعة.
• Cloudflare D1 — خدمة SQLite مُدارة تعمل بالقرب من المستخدم بقدر قُربه من بيئة تشغيل Cloudflare Workers ذاتها.
• Fly.io LiteFS — نظام ملفات موزّع يحوّل أي قاعدة SQLite إلى قاعدة منسوخة عالميًا دون أي تغيير في التطبيق.

ثلاث من هذه — Turso و D1 و LiteFS — وصلت إلى نضج الإنتاج في وقت متزامن أواخر 2025. وبحلول مطلع 2026، تبلوَر النموذج المعتمد.

نمط النسخة المُضمَّنة

الميزة الفارقة هي ما تسمّيه Turso بـ النسخ المُضمَّنة (embedded replicas). بدلًا من الاستعلام من قاعدة بيانات بعيدة عبر الشبكة، يفتح تطبيقك ملف SQLite محلّيًا يتزامن تلقائيًا مع قاعدة أساسية في السحابة. الكتابات تذهب إلى الأعلى، أمّا القراءات فتبقى محلّية.

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

import { createClient } from "@libsql/client";
 
const db = createClient({
  url: "file:local.db",
  syncUrl: "libsql://my-app-noqta.turso.io",
  authToken: process.env.TURSO_AUTH_TOKEN,
  syncInterval: 60,
});
 
await db.sync();
 
const result = await db.execute(
  "SELECT id, name FROM customers WHERE region = ?",
  ["mena"]
);

الاستعلام أعلاه يعمل ضد ملف SQLite محلي. لا توجد دورة شبكة. القراءات تكتمل في ميكروثوانٍ. واستدعاء sync() يبقي النسخة محدّثة مقابل القاعدة الأساسية في السحابة.

سواء كان تطبيق Next.js منشورًا على Vercel، أو واجهة Hono على Cloudflare Workers، أو عميل React Native على الجوال، النمط واحد والشيفرة واحدة.

بحث متجهي أصيل داخل SQLite

المعلَم الآخر لعام 2026 هو أن libSQL تشحن بحثًا متجهيًا أصيلًا. لا امتداد، ولا قاعدة بيانات متجهية منفصلة، ولا خط أنابيب للمزامنة. تُعرّف عمود تضمين وفهرسًا، ثم تستعلم.

CREATE TABLE articles (
  id INTEGER PRIMARY KEY,
  title TEXT,
  embedding F32_BLOB(1536)
);
 
CREATE INDEX articles_idx
  ON articles ( libsql_vector_idx(embedding) );
 
SELECT id, title
FROM articles
WHERE year >= 2025
ORDER BY vector_distance_cos(embedding, vector('[0.21, 0.04, ...]'))
LIMIT 5;

ثلاثة أمور تجعل هذا مميّزًا:

1. الفهرس المتّجهي يستخدم DiskANN، خوارزمية اختيرت تحديدًا لاستهلاك ذاكرة منخفض، وهو أمر مهم عند تشغيل آلاف قواعد البيانات الصغيرة على حافة متعددة المستأجرين.
2. يمكن دمج استعلامات المتجهات بحرية مع شروط علائقية مثل WHERE year >= 2025، وهو ما تتعامل معه معظم قواعد البيانات المتجهية المخصّصة بصعوبة.
3. لأن قاعدة البيانات محلية لوظيفتك، يحدث خط أنابيب RAG بأكمله — استرجاع التضمين، التصفية الهجينة، الترتيب — دون أي قفزات شبكة.

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

أين تناسب كل أداة

المنصات الأربع الكبرى لـ SQLite الموزّعة ليست متبادلة. كل منها مُحسَّنة لنموذج نشر مختلف.

Turso هي الخيار الصحيح عندما تريد قاعدة أساسية مُدارة في السحابة مع نسخ مُضمَّنة تلقائية عبر آلاف قواعد البيانات. SaaS متعددة المستأجرين — قاعدة بيانات لكل عميل — هي نقطة قوّتها.

libSQL (المُستضافة ذاتيًا) تناسب الفرق التي تريد القدرات الجديدة لـ Turso لكنها تحتاج إلى تشغيل قاعدة البيانات على بنيتها التحتية لأسباب الامتثال أو إقامة البيانات. هذا مهم لفرق منطقة الشرق الأوسط وشمال إفريقيا الخاضعة لقواعد توطين البيانات في تونس أو السعودية أو الإمارات.

Cloudflare D1 هي الاختيار الطبيعي إذا كانت حزمتك التقنية موجودة بالفعل على Cloudflare Workers أو Pages أو R2. تتكامل مباشرة مع بيئة تشغيل Workers وتُحاسَب ضمن حسابك الحالي على Cloudflare.

Fly.io LiteFS تفوز للفرق التي تشغّل تطبيقات قائمة معتمدة على SQLite وتحتاج إلى نسخ متماثل دون إعادة كتابة طبقة البيانات. أضف LiteFS، تحصل على نسخ عالمي.

متى يجب أن تختار Postgres مع ذلك

SQLite الموزّعة ليست بديلًا شاملًا. اختر Postgres أو أي قاعدة علائقية مركزية أخرى عندما:

• تحتاج إلى إنتاجية كتابة متزامنة كثيفة على مجموعة بيانات واحدة (سجلات مالية، مزايدات إعلانية).
• يعتمد عبء عملك على ميزات متقدمة لا تضاهيها SQLite — دوال نوافذ شاملة عبر مجموعات بيانات ضخمة جدًا، أو إجراءات مخزّنة معقّدة، أو فهرسة JSON غنية.
• يدير فريقك بالفعل Postgres على نطاق واسع وخبرته التشغيلية أثمن من مكسب الكمون.

الإطار الصادق: SQLite الموزّعة تفوز لأعباء العمل الكثيفة القراءة والموزّعة عالميًا والمنفصلة لكل مستأجر. هذا يصف معظم منتجات SaaS الحديثة.

مسار هجرة قابل للشحن فعلًا

للفرق التي تفكر في الانتقال، المسار الواقعي تدريجي:

1. ابدأ بمسار القراءة. اختر نقطة نهاية واحدة كثيفة القراءة، عادة استعلام لوحة تحكم أو نداء بحث، ووجّهها إلى نسخة Turso مُضمَّنة. قِس انخفاض الكمون.
2. انقل ملكية البيانات. هاجِر بيانات مستأجر واحد إلى Turso، واحتفظ بـ Postgres لبقيّتهم. تحقّق من النموذج التشغيلي.
3. اعتمد البحث المتّجهي بشكل أصيل. إذا كنت تشغّل أي ميزة استرجاع معزّزة بالذكاء الاصطناعي، استبدل قاعدة البيانات المتّجهية الخارجية بفهارس libSQL المتّجهية. تذكر معظم الفرق إسقاط خدمة كاملة من معماريتها.
4. أعد تقييم قاعدة البيانات المركزية. بعد ثلاثة إلى ستة أشهر، قرّر ما إذا كانت Postgres لا تزال تستحق مكانها، أو ما إذا كانت أعباء العمل المتبقية يمكن أن تنتقل.

هذا هو المسار الذي اتّبعته الفرق الشاحنة في الإنتاج خلال 2025 و 2026، وسبب التحول الواضح في مشهد موردي قواعد البيانات.

ماذا يعني هذا لفرق منطقة الشرق الأوسط وشمال إفريقيا

بالنسبة للمطورين والشركات الناشئة عبر منطقة الشرق الأوسط وشمال إفريقيا، تغيّر SQLite الموزّعة شيئين تحديدًا:

• الكمون. استضافة نسخة Postgres واحدة في فرانكفورت أو البحرين لا يزال يترك المستخدمين في تونس أو الرياض أو القاهرة يدفعون عشرات الميلي ثانية لكل استعلام. نسخة مُضمَّنة تعمل داخل عقدة Cloudflare أو Fly.io قريبة تخفّض ذلك إلى ميكروثوانٍ.
• التكلفة التشغيلية. SaaS صغيرة تخدم 200 عميل لم تعد بحاجة إلى عنقود Postgres مُدار. مشروع Turso بقاعدة بيانات لكل مستأجر يكلّف جزءًا بسيطًا ويتوسّع تلقائيًا.

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

الخلاصة

نضجت قاعدة البيانات الأكثر انتشارًا في التاريخ. حوّلت Turso و libSQL و Cloudflare D1 و LiteFS قاعدة SQLite من فضول مُضمَّن إلى خيار جدي للمنتجات العالمية. في عام 2026، لم يعد السؤال هل SQLite الموزّعة جاهزة للإنتاج، بل أيّ أعباء العمل في حزمتك يجب أن تنتقل أولًا.

إذا كنت تصمّم منتجًا جديدًا أو تعيد النظر في طبقة البيانات لديك هذا العام، فهذا هو القرار المعماري الأكثر أهمية.