SQLite در حال بلعیدن جهان است

پراستفاده‌ترین پایگاه داده‌ای که هرگز مستقر نکرده‌اید

SQLite روی بیش از یک تریلیون دستگاه نصب شده است. گوشی شما آن را دارد. مرورگر شما آن را دارد. هر نصب macOS همراه با آن عرضه می‌شود. این پایگاه داده، پایگاه داده پیامک در اندروید، ذخیره‌سازی بوکمارک در فایرفاکس و فراداده عکس‌ها در آیفون شما را تأمین می‌کند. با این حال، تا همین اواخر، اکثر توسعه‌دهندگان بک‌اند آن را یک اسباب‌بازی می‌دانستند — چیزی برای نمونه‌سازی اولیه، برنامه‌های موبایل و اسکریپت‌های محلی، نه برای اجرای یک سرویس وب واقعی.

این وضعیت به سرعت در حال تغییر است.

SQLite در واقع چیست

SQLite یک سرور پایگاه داده نیست. هیچ لایه شبکه‌ای، سیستم احراز هویت یا فرآیند پس‌زمینه‌ای برای مدیریت ندارد. این یک کتابخانه C است که یک فایل واحد روی دیسک را می‌خواند و می‌نویسد. شما آن را به برنامه خود متصل کرده و مستقیماً فراخوانی می‌کنید — بدون رشته اتصال، شماره پورت یا فایل پیکربندی برای مدیریت.

چیزی که دارد: انطباق کامل با ACID، یک پیاده‌سازی کامل SQL (توابع پنجره، CTE، پشتیبانی از JSON، جستجوی متن کامل)، عملکرد زیر میلی‌ثانیه‌ای پرس‌وجو برای بارهای کاری معمولی، و فرمت فایلی به قدری پایدار که تیم SQLite سازگاری با عقب را تا سال ۲۰۵۰ تضمین می‌کند. کل پایگاه داده یک فایل است که می‌توانید کپی کنید، ایمیل کنید یا در کنترل نسخه قرار دهید.

برای ۳۰ سال، این ترکیب آن را به پایگاه داده غالب برای موارد استفاده توکار تبدیل کرد — مواردی که به ماندگاری بدون زیرساخت نیاز دارید. اما «توکار» در حال تعریف دوباره است.

چرا استفاده در تولید واضح نبود

نقد سنتی به SQLite برای بارهای کاری سرور به دو محدودیت واقعی برمی‌گردد:

• هم‌روندی: SQLite از قفل‌گذاری در سطح فایل استفاده می‌کند. در حالت WAL (WAL = Write-Ahead Log)، خوانندگان نویسندگان را مسدود نمی‌کنند و بالعکس، اما همچنان در هر لحظه یک نویسنده دارید. بارهای کاری نوشتاری با هم‌روندی بالا صف می‌بندند.
• تک ماشین: پایگاه داده روی یک سیستم فایل زندگی می‌کند. هیچ تکرار داخلی، failover آماده‌باش، یا نوشتن چند منطقه‌ای وجود ندارد. اگر سرور شما از کار بیفتد، پایگاه داده شما نیز از کار می‌افتد.

اینها محدودیت‌های واقعی هستند. اما برای اکثر برنامه‌های وب، بی‌ربط هستند. میانگین برنامه CRUD دارای نسبت خواندن/نوشتن ۹۰٪ خواندن است. هم‌روندی نوشتن فراتر از چند ده درخواست در ثانیه، مشکلی است که اکثر برنامه‌ها هرگز نخواهند داشت. پیچیدگی Postgres — pooling اتصال، تأخیر تکرار، failover آماده‌باش، مهاجرت طرح‌واره در بین نسخه‌های تکراری — برای حل مشکلاتی وجود دارد که در مقیاسی که اکثر توسعه‌دهندگان در واقع در آن کار می‌کنند، وجود ندارند.

موج SQLite توزیع‌شده

اکوسیستمی که حول SQLite برای استفاده سرور پدید آمده است، مستقیماً محدودیت‌های باقی‌مانده را برطرف کرده است. سه پروژه در حال هدایت این تغییر هستند.

Turso و LibSQL

LibSQL یک انشعاب متن‌باز از SQLite است که توسط Turso نگهداری می‌شود. این انشعاب ویژگی‌هایی را اضافه می‌کند که SQLite را برای استقرارهای سرور غیرعملی می‌کرد: تکرار حالت WAL از طریق HTTP، دسترسی از راه دور از طریق یک پروتکل بومی، افزونه‌های قابل بارگذاری که به طور پیش‌فرض فعال هستند، و پشتیبانی از نسخه تکراری توکار — به این معنی که برنامه شما می‌تواند یک کپی محلی SQLite نگه دارد که از یک سرور اصلی از راه دور همگام‌سازی می‌شود. شما تأخیر خواندن محلی را با ماندگاری از راه دور دریافت می‌کنید.

نتیجه چیزی است که مانند یک پایگاه داده بدون سرور (serverless) احساس می‌شود اما مانند یک فایل محلی عمل می‌کند. سرویس میزبانی‌شده Turso به شما امکان می‌دهد در عرض چند ثانیه پایگاه داده ایجاد کرده و بدون دست زدن به فایل پیکربندی، آنها را در مناطق مختلف تکرار کنید. سطح رایگان آنها به قدری سخاوتمندانه است که برنامه‌های کوچک هرگز یک دلار پرداخت نمی‌کنند.

Cloudflare D1

Cloudflare D1 SQLite را در داخل Cloudflare Workers در لبه (edge) اجرا می‌کند. هنگامی که یک Worker در فرانکفورت از D1 پرس‌وجو می‌کند، به یک نمونه SQLite که در همان مرکز داده اجرا می‌شود ضربه می‌زند، نه اینکه از اقیانوس عبور کند تا به یک خوشه Postgres در ویرجینیا برسد. تأخیر پرس‌وجو که بر حسب صدها میلی‌ثانیه اندازه‌گیری می‌شد، به اعداد تک رقمی کاهش می‌یابد.

D1 تکرار را به صورت شفاف مدیریت می‌کند. شما روی یک سرور اصلی می‌نویسید، Cloudflare خواندن را به مکان‌های لبه تکرار می‌کند. API، SQL استاندارد است — می‌توانید از drizzle-orm، kysely یا پرس‌وجوهای خام استفاده کنید. این SQLite با یک لایه خواندن جهانی است که مجبور نبودید خودتان بسازید.

SQLite داخلی Bun

Bun از نسخه v1.1 با یک اتصال (binding) بومی SQLite عرضه می‌شود — بدون npm install، بدون کامپایل ماژول بومی، بدون وابستگی better-sqlite3 برای مدیریت. شما bun:sqlite را import کرده و یک پایگاه داده باز می‌کنید. همین. برای توسعه‌دهندگان جاوااسکریپت که سرویس‌های سبک یا ابزارهای خط فرمان می‌سازند، اصطکاک پذیرش SQLite به صفر رسیده است.

Rails 8 آن را به پیش‌فرض تبدیل کرد

مهم‌ترین سیگنال مبنی بر اینکه SQLite از یک آستانه عبور کرده است: Rails 8 که در اواخر سال ۲۰۲۴ منتشر شد، SQLite را به عنوان پایگاه داده پیش‌فرض برای برنامه‌های جدید عرضه می‌کند. این یک راحتی نمونه‌سازی اولیه نیست — DHH و تیم اصلی Rails به صراحت گفته‌اند که SQLite انتخاب درستی برای اکثر برنامه‌ها است و آنها روی ابزارهایی سرمایه‌گذاری کرده‌اند تا آن را برای تولید آماده کنند: solid_queue برای کارهای پس‌زمینه روی SQLite، solid_cache برای کش کردن، و یکپارچه‌سازی پشتیبان‌گیری مبتنی بر Litestream.

وقتی چارچوبی که الگوی برنامه وب مدرن را تعریف کرد، به طور پیش‌فرض از یک پایگاه داده مبتنی بر فایل استفاده می‌کند، گفتگوی صنعت تغییر کرده است.

بحث «SQLite برای همه چیز»

بحث ظریف نیست: برای ۸۰٪ از برنامه‌های وب، به Postgres نیاز ندارید. به یک pool اتصال نیاز ندارید. به یک نسخه تکراری نیاز ندارید. به یک پایگاه داده نیاز دارید که سریع، قابل اعتماد باشد و برای اجرا به یک مدیر سیستم نیاز نداشته باشد.

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 ارائه می‌دهد نیاز دارد یا خیر.

برای اکثر برنامه‌ها، پاسخ صادقانه منفی است.