SQLite: قاعدة البيانات التي لم تتوقعها السحابة — وما زالت تفوز

يوجد حوالي تريليون نشر نشط لـ SQLite في العالم. هذا الرقم، وفقًا لوثائق مشروع SQLite نفسه، ليس تقديرًا تسويقيًا — إنها حقيقة معمارية. كل iPhone يأتي مع SQLite. كل جهاز Android يشغله. يستخدمه Firefox لتخزين السجل والإشارات المرجعية وملفات تعريف الارتباط. يستخدمه Chrome كخلفية لقاعدة بياناته. Skype وDropbox وiTunes وVLC ومجموعة Adobe Creative Suite كلها تدمجه. توصي مكتبة الكونغرس الأمريكية به كتنسيق أرشيف. SQLite، حسب عدد النشر، هو محرك قاعدة البيانات الأكثر استخدامًا في الوجود — وحتى وقت قريب، كان معظم المطورين يعتقدون أنه شيء يُشحن داخل تطبيقات الهاتف المحمول، وليس بنية تحتية جادة.

هذا الإطار أصبح الآن عتيقًا. في عام 2026، يعمل SQLite داخل شبكة الحافة العالمية لـ Cloudflare، ويشغل التطبيقات الموزعة من خلال fork libSQL الخاص بـ Turso، ويشكل أساسًا لبنية تطبيقات local-first التي تجذب اهتمامًا هندسيًا جادًا. قاعدة البيانات التي قضت ثلاثين عامًا تُسمى "غير صالحة للإنتاج" تعيد تعريف معنى الإنتاج بهدوء.

ما هو SQLite حقًا

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

على الرغم من بساطتها، فإن SQLite متوافقة تمامًا مع ACID. عمليات الكتابة ذرية؛ القراءات المتزامنة مدعومة من خلال وضع WAL (سجل الكتابة المسبقة)؛ تنسيق القرص مستقر ومتوافق تمامًا مع الإصدارات السابقة منذ عام 2004. تدعم SQL-92 الكامل مع معظم SQL:1999، بما في ذلك دوال النوافذ وCTEs وعوامل JSON المضافة في الإصدارات الأحدث. تتم صيانة المشروع بواسطة فريق صغير تحت إهداء المجال العام — لا ترخيص، ولا حقوق نشر، ولا اتفاقيات مساهم.

بدأها ريتشارد هيب في عام 2000 لبرنامج المدمرة الصاروخية التابع للبحرية الأمريكية، حيث كان غياب مسؤول قاعدة البيانات قيدًا على التصميم، وليس إشرافًا. هذا الأصل يحدد كل شيء عن SQLite: لقد تم بناؤها لبيئات لا يمكنك فيها تحمل تكلفة خادم أو DBA أو اتصال شبكة. تلك القيود، كما اتضح، تصف بيئة الحوسبة الحافية بشكل شبه مثالي.

SQLite على الحافة: Cloudflare D1 وTurso وLiteFS

Cloudflare D1، الذي تم إطلاقه للتوفر العام في 2023 وتوسع بشكل كبير خلال 2024–2025، هو SQLite يعمل داخل Cloudflare Workers عبر أكثر من 300 موقع حافة في جميع أنحاء العالم. عندما ينفذ Worker استعلام D1، فإنه يعمل مقابل ملف SQLite في عقدة الحافة الأقرب للمستخدم. القراءات دون الميلي ثانية. يمكن لقاعدة البيانات التوسع إلى 10 GB لكل قاعدة بيانات بدون تزويد — تقوم بإنشاء قاعدة بيانات D1 في أمر CLI واحد وتكون متاحة فورًا عالميًا.

يحل D1 مشكلة الكتابة من خلال نموذج primary-replica: تذهب عمليات الكتابة إلى موقع أساسي ويتم نسخها بشكل غير متزامن إلى جميع عقد الحافة. بالنسبة لأعباء العمل الثقيلة القراءة — التي تصف معظم تطبيقات الويب — فإن ميزة الكمون على مثيل PostgreSQL أحادي المنطقة كبيرة. يبلغ Cloudflare أن D1 يخدم أكثر من 50 مليار صف مقروء شهريًا عبر قاعدة عملائه اعتبارًا من أوائل 2026.

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

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

SQLite عبر HTTP وأنماط الوصول الجديدة

أحد التطورات الأكثر إثارة للاهتمام في نظام SQLite البيئي هو ظهور طبقات الوصول المستندة إلى HTTP التي تجعله يتصرف أشبه بقاعدة بيانات تقليدية client-server دون التخلي عن مزاياه المضمنة. يعرض وضع الخادم في libSQL واجهة WebSocket وHTTP يمكن للعملاء الاتصال بها عن بُعد — مما يعني أنه يمكن الاستعلام من متصفح أو تطبيق جوال أو دالة serverless عن قاعدة بيانات SQLite تعمل على خادم باستخدام دلالات HTTP القياسية.

هذا مهم لأنه يفتح SQLite للبيئات التي لا يمكن فيها تضمين المكتبة مباشرة. تطبيق Next.js المنشور على Vercel لا يمكنه حزم مكتبة SQLite أصلية — لكن يمكنه إجراء طلبات HTTP إلى قاعدة بيانات Turso والحصول على نتائج استعلام SQL كـ JSON. تجربة المطور تكاد تكون مماثلة للاستعلام عن Postgres عبر pool اتصال، لكن المحرك الأساسي هو SQLite، بكل البساطة التشغيلية التي يعنيها ذلك.

Bun، بيئة تشغيل JavaScript التي تكتسب زخمًا كبديل أسرع لـ Node.js، تأتي مع دعم SQLite الأصلي من خلال وحدة bun:sqlite — بدون الحاجة إلى npm install، ولا تجميع وحدة أصلية، ولا node-gyp. const db = new Database("mydb.sqlite"); هو كل الإعداد. أرقام الأداء التي يستشهد بها Bun لتنفيذ SQLite الخاص به — أكثر من 4 ملايين قراءة في الثانية على كمبيوتر محمول — تعكس مدى سرعة قاعدة بيانات بدون حمل شبكة عندما تعمل في نفس عملية كود تطبيقك.

الهندسة local-first وصعود CRDTs

حركة local-first في تطوير تطبيقات الويب مبنية على ادعاء محدد: أن الهندسة الصحيحة لمعظم التطبيقات هي تلك التي تعيش فيها قاعدة البيانات على العميل، وتكون القراءات فورية لأنها تصل إلى التخزين المحلي، ويحدث التزامن مع الخادم في الخلفية. تجربة المستخدم أسرع، والقدرة دون اتصال مدمجة، ويصبح الخادم مرحّل تزامن بدلاً من عنق زجاجة استعلام.

SQLite هو الخيار الطبيعي لهذه الهندسة لأنه يعمل في كل مكان — في المتصفح عبر WebAssembly (wa-sqlite، sql.js)، في تطبيقات Electron أصلاً، على الجوال عبر SQLite المدمج في النظام الأساسي، وعلى عقد الحافة عبر D1 أو Turso. نفس استعلامات SQL تعمل عبر كل هذه البيئات على ملفات متوافقة أساسًا مع بعضها البعض.

المشكلة الصعبة في الهندسة local-first هي حل النزاعات: إذا كتب عميلان إلى نسخة محلية من SQLite أثناء عدم الاتصال، كيف تدمج هذه الكتابات عند إعادة الاتصال؟ هنا تدخل CRDTs (أنواع البيانات المكررة الخالية من النزاعات) في الصورة. cr-sqlite، إضافة SQLite طورها مات ونلاو في Vlcn.io، تنفذ دلالات CRDT مباشرة في SQLite من خلال آلة جداول SQL القياسية بساعة لامبورت ووظيفة دمج. يمكن دمج قاعدتي بيانات cr-sqlite بشكل حتمي دون سلطة مركزية. أي نزاع على مستوى الصف يتم حله بواسطة قواعد دمج CRDT، وليس بواسطة خادم يقرر أي كتابة تفوز.

هذا المزيج — SQLite للتخزين، CRDTs لدلالات الدمج، مرحّل تزامن للاتصال — هو الهندسة خلف أدوات مثل ElectricSQL وReplicache وZero (من فريق Rocicorp الذي بنى Replicache). لم يعد تجريبيًا بحتًا: Linear، أداة إدارة المشاريع، تستخدم هندسة قائمة على SQLite محلية أولى لتطبيق سطح المكتب الخاص بها، وتنسب إحساسها السريع إلى حقيقة أن كل تفاعل يصل إلى قاعدة بيانات محلية بدلاً من API عن بُعد.

أدوات المطورين في 2026

لحق نظام ORM والأدوات البيئية بدور SQLite الموسع. Drizzle ORM، أحد أسرع ORM نموًا في TypeScript، يعامل SQLite كهدف من الدرجة الأولى إلى جانب PostgreSQL وMySQL — مع محولات خاصة لـ better-sqlite3، وSQLite الأصلي لـ Bun، وlibSQL، وD1، وTurso. استنتاج النوع في Drizzle يعني أن مخطط SQLite الخاص بك يقود أنواع TypeScript بدون حمل وقت تشغيل.

أضاف Prisma دعم D1 في 2024 مع نموذج محولات السائق الخاص به، مما يسمح لمحرك استعلام Prisma بالعمل ضد Cloudflare D1 عبر HTTP API الخاص بـ D1. يظل تعريف مخطط Prisma متطابقًا سواء كنت تستهدف Postgres أو D1؛ فقط تهيئة العميل تتغير. better-sqlite3، ربط Node.js لـ SQLite بواسطة جوشوا وايز، يظل الخيار الأفضل للوصول المتزامن عالي الأداء إلى SQLite في Node.js من جانب الخادم — تصميم API المتزامن هو اختيار متعمد، يطابق الطبيعة المتزامنة لـ SQLite ويتجنب حمل async الذي يعاني منه معظم برامج تشغيل قواعد البيانات.

أين يقصر SQLite حقًا

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

يساعد وضع WAL بشكل كبير في أعباء العمل الثقيلة القراءة مع كتابات متفرقة: القرّاء لا يحجبون الكتّاب أبدًا والكتّاب لا يحجبون القرّاء أبدًا. لكن WAL لا يغير القيد الأساسي للكاتب الواحد. إذا كان عنق الزجاجة لديك هو تزامن الكتابة، فأنت بحاجة إلى قاعدة بيانات مع مدير قفل مصمم لذلك — PostgreSQL، أو MySQL، أو نظام موزع مثل CockroachDB.

لا يوجد أيضًا نسخ متماثل مدمج. SQLite القياسي ليس لديه مفهوم primary/replica، ولا شحن WAL، ولا فتحات نسخ منطقية. كل حل نسخ متماثل في النظام البيئي — LiteFS، والنسخ المكررة المضمنة في Turso، وcr-sqlite — هو طبقة مبنية فوق SQLite بواسطة أطراف ثالثة. هذا يعني أن إعدادات النسخ تحمل تعقيدًا تشغيليًا أكبر مما تبدو: أنت تدير نظامين (SQLite بالإضافة إلى طبقة النسخ) بدلاً من نظام واحد. وتتفاوت ضمانات الاتساق: النسخ المكررة المضمنة في Turso متسقة في النهاية، وليست متسقة بقوة — الكتابة على نسخة واحدة قد لا تكون مرئية فورًا على نسخة أخرى.

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

متى تختار SQLite، ومتى لا

SQLite هو الخيار الصحيح عندما تكون نسبة القراءة إلى الكتابة عالية، وعندما تريد صفر حمل تشغيلي، وعندما تبني للحافة أو للهندسات local-first، أو عندما تقدم أداة مطور أو CLI أو تطبيقًا مضمنًا حيث يكون خادم قاعدة البيانات أمرًا سخيفًا. لقد جعله D1 وTurso قابلاً للتطبيق لتطبيقات الويب الإنتاجية ذات المستخدمين العالميين، بشرط أن تكون هذه التطبيقات ثقيلة القراءة ويمكنها تحمل الاتساق النهائي في الكتابة.

يظل PostgreSQL الخيار الصحيح عندما تحتاج إلى تزامن كتابة قوي، وقفل على مستوى الصف، وطوبولوجيا نسخ معقدة، أو النظام البيئي العميق للإضافات (PostGIS، pgvector، TimescaleDB) الذي بناه Postgres على مدى ثلاثين عامًا. MySQL وMariaDB تحتلان أراضي مماثلة. قاعدة بيانات موزعة مثل CockroachDB أو PlanetScale مبررة عندما تحتاج إلى توسع أفقي في الكتابة مع ضمانات اتساق قوية عبر المناطق — وهي حالة استخدام لم يتم تصميم SQLite أبدًا لمعالجتها.

السؤال الأكثر إثارة للاهتمام لعام 2026 ليس "SQLite مقابل Postgres" بل "أين ينتمي كل منهما في نفس النظام؟" تستخدم العديد من الهندسات الإنتاجية الآن كليهما: SQLite على الحافة للبيانات الخاصة بالمستخدم منخفضة الكتابة (حالة الجلسة، التفضيلات، الخلاصات لكل مستخدم) وPostgres في المركز للبيانات المشتركة عالية الكتابة (المعاملات، المخزون، الرسائل). قاعدة البيانات التي لم تتوقعها السحابة وجدت مكانها في المكدس — ليس عن طريق استبدال ما جاء قبلها، ولكن عن طريق التعامل مع الحالات التي كان فيها إعداد كتلة PostgreSQL دائمًا الإجابة الخاطئة.