SQLite ليست قاعدة بيانات ألعاب — وتطبيقات إنتاجية متزايدة تثبت ذلك

SQLite هي محرك قاعدة البيانات الأكثر انتشارًا على الإطلاق. تعمل داخل كل جهاز Android، وكل iPhone، وكل متصفح سطح مكتب، وكل Mac، ومعظم أنظمة Windows. يُقدر أن هناك أكثر من تريليون قاعدة بيانات SQLite قيد الاستخدام النشط. ولطالما كانت القاعدة الضمنية في تطوير الويب هي: SQLite مناسبة للتطوير والاختبار، لكنك تنتقل إلى Postgres أو MySQL قبل الشحن.

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

الاعتراض التقليدي

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

الاعتراض الثاني تشغيلي: إذا كان تطبيقك يعمل على خوادم متعددة، لا يمكنهم مشاركة ملف SQLite. قواعد البيانات الموزعة مثل Postgres عبر TCP/IP مصممة لهذا؛ SQLite ليست كذلك. هذا جعل SQLite غير قابلة للتطبيق أساسًا في تطبيقات الويب ذات التوسع الأفقي.

كلا الاعتراضين حقيقي. لكن لا شيء منهما عالمي.

ما تغير: نظام التكرار البيئي

في 2021، أصدر بن جونسون Litestream — أداة مفتوحة المصدر تدفع ملف WAL الخاص بـ SQLite إلى تخزين كائنات متوافق مع S3 بزمن شبه حقيقي. الفكرة: تحصل على نسخ احتياطي تلقائي خارج الموقع مع RPO أقل من ثانية، دون تغيير كود التطبيق أو التحول إلى قاعدة بيانات خادم-عميل. Litestream لا يحل قيد الكاتب الواحد؛ يحل مشكلة التعافي من الكوارث والنسخ الاحتياطي التي جعلت SQLite تبدو غير آمنة للإنتاج. بالنسبة للعديد من حالات الاستخدام، هذا هو القلق الأكثر إلحاحًا.

Fly.io أخذ هذا أبعد مع LiteFS، وهو نظام ملفات موزع يستخدم FUSE لاعتراض كتابات SQLite وتكرارها إلى العقد المكررة. يمنحك LiteFS عقدة رئيسية تقبل الكتابات وعقد قراءة مكررة تتبعها — مشابهة لتكرار التدفق في Postgres، لكن لـ SQLite. التطبيقات التي يمكنها توجيه الكتابات إلى العقدة الرئيسية والقراءات إلى أي مكرر تستفيد من التوسع الأفقي للقراءة دون تغيير محرك قاعدة البيانات.

أكثر الجهود طموحًا هو Turso، المبني على libSQL — فرع من قاعدة كود SQLite يضيف بروتوكول شبكة، وتعددية إيجار، وتكرار على الحافة. فكرة Turso هي "SQLite على الحافة": كل مستخدم يحصل على شريحة قاعدة بيانات تعمل جغرافيًا قريبة منه، مما يزيل زمن الوصول لقاعدة بيانات مركزية. الشركة جمعت 32 مليون دولار في جولة Series A عام 2023. libSQL مفتوحة المصدر؛ خدمة Turso المدارة هي المنتج التجاري. خدمة قاعدة بيانات D1 من Cloudflare تستخدم بنية مماثلة، تقدم تخزينًا متوافقًا مع SQLite كأولية بدون خادم.

حجة الأداء

للتطبيقات حيث تعيش قاعدة البيانات على نفس الجهاز مثل خادم التطبيق — وهذا صحيح لنسبة كبيرة من التطبيقات المستضافة ذاتيًا والصغيرة إلى المتوسطة — غالبًا ما تتفوق SQLite مع وضع WAL على Postgres أو MySQL في معايير الأداء لأحمال العمل OLTP كثيفة القراءة. السبب هو إلغاء زمن وصول الشبكة: استعلام SQLite المحلي لا يعبر اتصال TCP. تكلفة رحلة ذهاب وإياب عبر الشبكة إلى خادم Postgres، حتى على localhost، تبلغ بضع مئات من الميكروثواني. عند أحجام استعلام عالية، يتراكم هذا.

ورقة COST لعام 2015 ("Scalability! But at what COST?") قدمت نقطة ذات صلة في سياق معالجة الرسوم البيانية الموزعة: جهاز واحد بتشغيل كود أحادي الخيط مضبوط جيدًا غالبًا ما يتفوق على الأنظمة الموزعة مثل Hadoop للرسوم البيانية التي تتسع في RAM. الرؤية تعمم: الأنظمة الموزعة لها تكاليف إضافية، وإذا كانت بياناتك تناسب جهازًا واحدًا، فقد تدفع تلك التكلفة دون فائدة.

وضع WAL في SQLite مُحسَّن بشكل ممتاز لقراءة التزامن العالي. المعايير من Turso ومطورين مستقلين تظهر باستمرار أن SQLite تتعامل مع عشرات الآلاف من القراءات في الثانية على أجهزة متواضعة، ضمن نطاق معظم تطبيقات الويب الإنتاجية.

من يفعل هذا بالفعل

37signals — الشركة التي تقف وراء Basecamp وHey — كانت أعلى صوت مؤيد علنيًا. مقال DHH في 2023 الذي جادل بأن SQLite مع Litestream كافية لمعظم تطبيقات الويب أثار نقاشًا واسعًا. 37signals تستخدم نموذج "قاعدة بيانات واحدة لكل عميل" لبعض بنيتها التحتية، حيث تصبح خاصية ملف واحد لكل قاعدة بيانات في SQLite ميزة: بيانات كل عميل معزولة في ملفها الخاص، والنسخ الاحتياطي بسيط جدًا.

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

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

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

مجموعات البيانات الكبيرة جدًا تطرح تحديات أيضًا. SQLite تدعم قواعد بيانات حتى 28 تيرابايت نظريًا، لكن الأداء العملي على قواعد بيانات تزيد عن بضع مئات غيغابايت يتدهور. ميزات Postgres مثل vacuum وautovacuum والتقسيم ناضجة ومفهومة جيدًا على نطاق واسع؛ آليات SQLite المكافئة أبسط وأقل اختبارًا في الأحجام الكبيرة.

القاعدة الأساسية الناشئة من المجتمع: إذا كان QPS الكتابي أقل من بضعة آلاف في الثانية ومجموعة بياناتك تناسب قرصًا واحدًا بشكل مريح، فإن SQLite مع WAL تستحق التقييم الجاد. إذا كنت بحاجة إلى كتابات متعددة الرؤوس، أو تكرار متزامن عبر مراكز بيانات، أو أمان على مستوى الصف مع هرميات أدوار معقدة، فإن Postgres لا تزال الأداة الصحيحة.

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