SQLite يلتهم العالم

قاعدة البيانات الأكثر انتشارًا التي لم تنشرها أبدًا

تم تثبيت SQLite على أكثر من تريليون جهاز. هاتفك يحتوي عليها. متصفحك يحتوي عليها. كل تثبيت لنظام macOS يأتي بها. تدير قاعدة بيانات SMS على أندرويد، وتخزين الإشارات المرجعية في فايرفوكس، وبيانات الصور الوصفية على آيفونك. ومع ذلك، حتى وقت قريب، كان معظم مطوري الواجهة الخلفية يتعاملون معها كلعبة — شيء للنماذج الأولية، وتطبيقات الهاتف المحمول، والنصوص البرمجية المحلية، وليس لتشغيل خدمة ويب حقيقية.

هذا يتغير بسرعة.

ما هي SQLite في الواقع

SQLite ليست خادم قاعدة بيانات. ليس لديها طبقة شبكة، ولا نظام مصادقة، ولا خفي لإدارته. إنها مكتبة C تقوم بقراءة وكتابة ملف واحد على القرص. تقوم بربطها بتطبيقك واستدعائها مباشرة — لا سلاسل اتصال، ولا أرقام منافذ، ولا ملفات تهيئة لإدارتها.

ما تمتلكه: الامتثال الكامل لـ ACID، وتنفيذ كامل لـ SQL (دوال النوافذ، CTEs، دعم JSON، البحث النصي الكامل)، وأداء استعلامات أقل من ميلي ثانية لأعباء العمل النموذجية، وتنسيق ملف مستقر لدرجة أن فريق SQLite يضمن التوافق مع الإصدارات السابقة حتى عام 2050. قاعدة البيانات بأكملها هي ملف واحد يمكنك نسخه، أو إرساله بالبريد الإلكتروني، أو وضعه في نظام التحكم بالإصدارات.

لمدة 30 عامًا، جعل هذا المزيج منها قاعدة البيانات المهيمنة لحالات الاستخدام المضمنة — النوع الذي تحتاج فيه إلى استمرارية بدون بنية تحتية. لكن "مضمنة" يتم إعادة تعريفها.

لماذا لم يكن الاستخدام الإنتاجي واضحًا

الانتقاد التقليدي لـ SQLite لأعباء عمل الخادم يعود إلى قيدين حقيقيين:

التزامن: تستخدم SQLite قفلًا على مستوى الملف. في وضع WAL (WAL = سجل الكتابة المسبقة)، لا يحجب القراء الكتّاب والعكس صحيح، لكن لا يزال لديك كاتب واحد في كل مرة. أعباء عمل الكتابة عالية التزامن ستتراكم في طابور.
جهاز واحد: قاعدة البيانات تعيش على نظام ملفات. لا يوجد نسخ متماثل مدمج، ولا تجاوز فشل احتياطي، ولا كتابة متعددة المناطق. إذا مات خادمك، تموت قاعدة بياناتك.

هذه قيود حقيقية. لكن بالنسبة لمعظم تطبيقات الويب، فهي غير ذات صلة. تطبيق CRUD العادي لديه نسبة قراءة/كتابة تبلغ 90% قراءات. التزامن في الكتابة بما يتجاوز بضع عشرات من الطلبات في الثانية هو مشكلة لن يواجهها معظم التطبيقات أبدًا. تعقيد Postgres — تجميع الاتصالات، تأخر النسخ المتماثل، تجاوز فشل الاستعداد، ترحيل المخطط عبر النسخ المتماثلة — موجود لحل مشاكل غير موجودة على النطاق الذي يعمل به معظم المطورين في الواقع.

موجة SQLite الموزعة

النظام البيئي الذي ظهر حول SQLite للاستخدام على الخادم عالج القيود المتبقية بشكل مباشر. ثلاثة مشاريع تقود هذا التحول.

Turso و LibSQL

LibSQL هو فرع مفتوح المصدر من SQLite يتم صيانته بواسطة Turso. يضيف الميزات التي جعلت SQLite غير عملية لنشر الخوادم: النسخ المتماثل لوضع WAL عبر HTTP، والوصول عن بُعد عبر بروتوكول أصلي، والإضافات القابلة للتحميل مفعلة افتراضيًا، ودعم النسخة المتماثلة المضمنة — مما يعني أن تطبيقك يمكنه الاحتفاظ بنسخة محلية من SQLite تتم مزامنتها من قاعدة رئيسية عن بُعد. تحصل على زمن وصول محلي للقراءة مع متانة عن بُعد.

النتيجة هي شيء يشبه قاعدة بيانات بدون خادم لكنه يعمل مثل ملف محلي. خدمة Turso المستضافة تتيح لك إنشاء قواعد بيانات في ثوانٍ ونسخها عبر المناطق دون لمس ملف تهيئة. طبقتهم المجانية سخية لدرجة أن التطبيقات الصغيرة لا تدفع دولارًا واحدًا أبدًا.

Cloudflare D1

Cloudflare D1 تشغل SQLite داخل Cloudflare Workers على الحافة. عندما يقوم Worker في فرانكفورت بالاستعلام عن D1، فإنه يصل إلى مثيل SQLite يعمل في نفس مركز البيانات، وليس عبور محيط للوصول إلى مجموعة Postgres في فرجينيا. زمن وصول الاستعلام الذي كان يُقاس بمئات الميلي ثانية ينخفض إلى أرقام فردية.

D1 تدير النسخ المتماثل بشفافية. تكتب إلى قاعدة رئيسية، وتقوم Cloudflare بنسخ القراءات إلى مواقع الحافة. واجهة API هي SQL قياسية — يمكنك استخدام drizzle-orm أو kysely أو استعلامات خام. إنها SQLite مع طبقة قراءة عالمية لم تضطر لبنائها.

SQLite المدمجة في Bun

Bun يأتي مع ربط أصلي لـ SQLite منذ الإصدار v1.1 — لا حاجة لـ npm install، ولا تجميع لوحدة أصلية، ولا تبعية better-sqlite3 لإدارتها. تقوم باستيراد bun:sqlite وتفتح قاعدة بيانات. هذا كل شيء. لمطوري JavaScript الذين يبنون خدمات خفيفة أو أدوات CLI، انخفضت مقاومة تبني SQLite إلى الصفر.

Rails 8 جعلها الافتراضية

أهم إشارة على أن SQLite قد تجاوزت عتبة معينة: Rails 8، الذي صدر في أواخر 2024، يأتي مع SQLite كقاعدة بيانات افتراضية للتطبيقات الجديدة. هذه ليست وسيلة راحة للنماذج الأولية — DHH وفريق Rails الأساسي كانوا واضحين أن SQLite هي الخيار الصحيح لمعظم التطبيقات، وقد استثمروا في أدوات لجعلها جاهزة للإنتاج: solid_queue للمهام الخلفية على SQLite، وsolid_cache للتخزين المؤقت، وتكامل النسخ الاحتياطي القائم على Litestream.

عندما يجعل الإطار الذي عرّف نمط تطبيق الويب الحديث قاعدة بيانات قائمة على الملفات كخيار افتراضي، فإن النقاش في الصناعة قد تحول.

حجة "SQLite لكل شيء"

الحجة ليست خفية: بالنسبة لـ 80% من تطبيقات الويب، لا تحتاج إلى Postgres. لا تحتاج إلى تجمع اتصالات. لا تحتاج إلى نسخة متماثلة. تحتاج إلى قاعدة بيانات سريعة وموثوقة ولا تتطلب مسؤول أنظمة لتشغيلها.

SQLite تمنحك:

بدون تهيئة — لا خادم لبدء التشغيل، ولا مستخدم لإنشائه، ولا منفذ لفتحه
إعداد فوري — أنشئ ملفًا، وابدأ في كتابة SQL
نسخ احتياطي تافه — انسخ الملف، أو استخدم Litestream للنسخ المتماثل المستمر إلى S3
أداء قراءة ممتاز — أقل من ميلي ثانية للاستعلامات المفهرسة على قواعد بيانات يصل حجمها إلى عشرات الجيجابايت
ضمانات ACID — وضع WAL يمنحك قراءات متزامنة وأمانًا من الأعطال دون ضبط

البساطة التشغيلية تتراكم. عندما تكون قاعدة بياناتك ملفًا، يكون نشرك أبسط. بيئة التطوير الخاصة بك تطابق الإنتاج تمامًا. التصحيح أسهل. يمكنك فتح قاعدة البيانات في DB Browser for SQLite والنظر إلى البيانات مباشرة.

أين لا تزال غير مناسبة

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

النظام البيئي لـ Postgres أعمق أيضًا: إضافات أفضل (pgvector، PostGIS، TimescaleDB)، وأدوات مراقبة أكثر نضجًا، وعقود من المعرفة التشغيلية، والتحكم في التزامن متعدد الإصدارات الذي يعالج تنازع الكتابة بشكل أكثر أناقة. إذا كنت تبني نظامًا حيث إنتاجية الكتابة هي عنق الزجاجة، فإن Postgres لا يزال الخيار الصحيح.

التحول حقيقي

النمط هنا ليس جديدًا. انتقلت SQLite من "لعبة" إلى "خيار جاد" من خلال حل المشاكل التي أبقتها في العالم المضمن — وقد فعلت ذلك ليس بأن أصبحت أكثر تعقيدًا، بل بإلهام نظام بيئي أضاف القطع المفقودة حولها. LibSQL أضاف النسخ المتماثل. D1 أضافت طبقة الحافة. Litestream أضاف النسخ الاحتياطي المستمر. Bun أزال مقاومة التثبيت.

النتيجة هي محرك قاعدة بيانات تم إثبات جاهزيته للإنتاج على تريليون جهاز، ولا يتطلب بنية تحتية للتشغيل، ولديه الآن إجابات موثوقة للاعتراضين اللذين كانا يستبعدانه سابقًا. السؤال ليس ما إذا كانت SQLite يمكنها التعامل مع تطبيقك — بل هو ما إذا كان تطبيقك يحتاج حقًا إلى ما توفره Postgres.

بالنسبة لمعظم التطبيقات، الإجابة الصادقة هي لا.