SQLite در عصر ایجنت‌ها: چرا Turso همان دیتابیس آشنایی است که برای سال ۲۰۲۶ نیاز داریم؟

برای هر مهندس داده یا توسعه‌دهنده‌ای، نام SQLite یادآور پایداری، سادگی و کارایی است. یک دیتابیس تک‌فایلی، بدون نیاز به سرور، که دهه‌هاست در میلیاردها دستگاه، از گوشی‌های موبایل تا هواپیماها، به صورت بی‌نقص کار می‌کند. این سادگی و ایزوله‌سازی، دقیقاً همان ویژگی‌هایی است که برای دنیای جدید ایجنت‌های هوش مصنوعی و Sandboxهای عملیاتی نیاز داریم؛ جایی که هر ایجنت باید محیطی امن و مجزا برای خود داشته باشد.

اما یک مشکل وجود دارد: SQLite برای دنیایی طراحی شده بود که در آن یک کاربر یا یک پردازش با یک فایل صحبت می‌کرد. با اینکه برای خواندن همزمان بهینه است، اما در نوشتن، یک قفل بزرگ در سطح کل دیتابیس اعمال می‌کند. در نتیجه، در هر لحظه فقط یک نفر می‌تواند بنویسد. این محدودیت، استفاده از آن را در سیستم‌های مدرن و توزیع‌شده تقریباً غیرممکن می‌کرد.

حالا تصور کنید چه می‌شد اگر می‌توانستیم روح SQLite — یعنی سادگی، قابل حمل بودن و پایداری — را حفظ کنیم، اما محدودیت‌های آن را با مهندسی مدرن برطرف سازیم؟

این دقیقاً فلسفه پیدایش Turso است.

Turso یک دیتابیس توزیع‌شده مبتنی بر libSQL (یک فورک متن‌باز از SQLite) است که با Rust بازنویسی شده تا سه مشکل اساسی SQLite را حل کند:

1. محدودیت تک‌نویسنده (Single-Writer Bottleneck): با پیاده‌سازی MVCC، Turso به چندین کاربر یا ایجنت اجازه می‌دهد به طور همزمان و بدون انتظار در صف، در دیتابیس بنویسند.
2. عدم وجود Replication: Turso به شما اجازه می‌دهد از دیتابیس خود کپی‌های (Replica) متعددی در نقاط مختلف جهان بسازید تا کاربران از نزدیک‌ترین نقطه به خودشان داده‌ها را با تأخیر نزدیک به صفر بخوانند.
3. نبود Point-in-Time-Recovery: این قابلیت به شما امکان می‌دهد وضعیت دیتابیس را به هر ثانیه‌ای در گذشته برگردانید.

بیایید این مشکلات اساسی SQlite را با هم مرور کنیم تا دقیق تر متوجه شویم این دیتابیس تازه نفس که خود را جایگزین SQlite می داند دقیقا چه کاری برای ما انجام خواهد داد.

چرا SQLite برای پروژه‌های بزرگ کم می‌آورد؟

مشکل خود SQLite نیست؛ مشکل زمانی شروع می‌شود که می‌خواهید این دیتابیس ساده را در دنیای واقعی با ترافیک بالا، کاربران همزمان و سرورهای توزیع‌شده به کار بگیرید.

۱. گلوگاه همزمانی: فقط یک نفر حق نوشتن دارد!

بزرگترین نقطه‌ضعف SQLite این است: در هر لحظه فقط یک تراکنش نوشتن (Write) می‌تواند انجام شود. به محض شروع یک عملیات نوشتن، بقیه درخواست‌ها قفل شده و در صف منتظر می‌مانند. در یک اپلیکیشن با کاربران زیاد، این موضوع به سرعت منجر به خطای معروف SQLITE_BUSY و از کار افتادن سیستم می‌شود.

۲. دردسر توزیع‌پذیری: دیتابیس تک‌نقطه‌ای

SQLite برای اجرا روی یک سیستم و یک فایل مشخص طراحی شده و هیچ قابلیت داخلی برای کپی‌برداری (Replication) بین سرورهای مختلف ندارد. در معماری ابری امروز که کاربران شما در سراسر جهان پراکنده هستند، این یعنی تأخیر (Latency) شدید برای هر کسی که از سرور اصلی دور است.

جادوی Turso: بازنویسی قوانین SQLite با زبان Rust

تیم Turso که ابتدا سعی کرد با بازنویسی و بهبود کدهای اصلی SQlite این مشکلات را برطرف کند، به سرعت فهمید که با وصله‌پینه کردن کدهای قدیمی C به جایی نمی‌رسد. بنابراین، آن‌ها کل موتور SQLite را از صفر با زبان Rust بازنویسی کردند. این نسخه جدید تمام خوبی‌های SQLite (تک‌فایلی، سبک، بدون کانفیگ) را حفظ کرده، اما محدودیت‌های بنیادین آن را از بین برده است:

• نوشتن همزمان توسط چندین کاربر (MVCC): دیگر خبری از صف و خطای SQLITE_BUSY نیست. Turso به چندین تراکنش اجازه می‌دهد به طور همزمان بنویسند، که سرعت را تا ۴ برابر افزایش می‌دهد.
• نسخه‌های محلی با تأخیر صفر: می‌توانید یک کپی (Replica) از دیتابیس را در نزدیک‌ترین سرور به کاربر قرار دهید. این کار باعث می‌شود سرعت خواندن داده‌ها به میکروثانیه (تقریباً صفر) برسد و عملیات نوشتن به صورت غیرهمزمان (Async) با سرور اصلی هماهنگ شود.
• پشتیبانی از پردازش ناهمگام (Async I/O): کاملاً هماهنگ با معماری‌های مدرن بدون سرور (Serverless) و لبه (Edge).
• جستجوی برداری توکار برای هوش مصنوعی: بدون نیاز به دیتابیس‌های جانبی، مستقیماً کوئری‌های Vector Search را برای پروژه‌های RAG و AI اجرا کنید.

چرا این معماری برای عصر ایجنت‌ها حیاتی است و شما کجاها می‌توانید از آن استفاده کنید؟

در معماری سنتی، دیتابیس یک «پردازش» (Process) سنگین بود که باید همیشه روشن می‌ماند و فقط یک نمونه از آن در کل سیستم وجود داشت. اما در معماری Turso، هر دیتابیس یک «فایل» است. این تغییر پارادایم، برای مهندسان داده و معماران سیستم، فرصت‌های عملی جدیدی را باز می‌کند. بیایید با چهار سناریوی مشخص، ببینیم این دیتابیس دقیقاً کجاها می‌تواند به کارتان بیاید.

۱. میلیون‌ها دیتابیس مجزا برای میلیون‌ها ایجنت یا کاربر

در Turso، دیتابیس‌ها به جای اینکه فرایندهای سنگین باشند، «فایل» هستند. این یعنی می‌توانید به هر ایجنت، کاربر یا مستأجر در معماری Multi-Tenant، دیتابیس اختصاصی خودش را بدهید، بدون اینکه سرورتان به دلیل بار پردازشی از کار بیفتد. Turso از این مدل معماری «چند-دیتابیسی» (many-database architecture) به صورت بومی پشتیبانی می‌کند: برخی از کاربران Turso Cloud بیش از یک میلیون دیتابیس را در حال اجرا دارند و سیستم بدون کوچکترین کندی همچنان پاسخگو است.

چه موقع از این قابلیت استفاده کنید؟

• ساخت اپلیکیشن‌های Multi-Tenant SaaS که هر مشتری باید داده‌های کاملاً جداشده از دیگران داشته باشد. برنامه رایگان Turso تا ۵۰۰ دیتابیس را پوشش می‌دهد و پلن‌های اسکیل‌شونده تا ۱۰,۰۰۰ دیتابیس را بدون محدودیت واقعی ادامه می‌دهند.
• سیستم‌های چند-ایجنتی (multi-agent orchestration) که هر ایجنت باید حافظه (Memory) و وضعیت عملیاتی خودش را در یک Sandbox ایزوله نگهداری کند. با دادن یک دیتابیس جدا به هر ایجنت، دیگر خبری از جنگ منابع (resource contention) یا نشت داده بین ایجنت‌ها نیست.
• اپلیکیشن‌های بازیابی‌محور (RAG) که روی خود دستگاه کاربر اجرا می‌شوند — می‌توانید دیتابیس و Embedding‌های جستجوی معنایی را کاملاً داخل گوشی یا مرورگر کاربر ذخیره کنید، بدون اینکه نیاز به تماس شبکه داشته باشید.
• Sharding افقی در مقیاس عظیم — به جای مدیریت یک دیتابیس عظیم که به سختی Shard می‌شود، هر Shard را به عنوان یک دیتابیس Turso مجزا مدیریت کنید و از قابلیت Branching مثل Git روی دیتابیس‌ها برای تست و رول‌بَک سریع استفاده کنید.

۲. جستجوی برداری بومی (Native Vector Search) — حذف پایگاه‌های جداگانه

در معمولی‌ترین معماری RAG امروز، شما حداقل به سه مؤلفه نیاز دارید: یک پایگاه داده رابطه‌ای برای داده‌های اصلی، یک پایگاه داده برداری مثل Pinecone یا Qdrant برای Embedding‌ها، و یک Glue Code برای همگام‌سازی این دو. Turso این سه را در یک SQLite فایل ترکیب کرده است. نوع داده vector و توابع vector_distance_cos مستقیماً در SQL در دسترس است و پردازش Embedding حتی با مدل‌های محلی مثل all-MiniLM-L6-v2 (فقط ۲۲ مگابایت) به صورت کامل Offline امکان‌پذیر است.

چه موقع از این قابلیت استفاده کنید؟

• ساخت موتور جستجوی معنایی بر روی کد یا مستندات داخلی — دقیقاً مثل پروژه codemogger که Turso ساخته است، می‌توانید پایگاه کد سازمان را Chunk به Chunk به Embedding تبدیل کنید و جستجوهایی مثل «کدام تابع احراز هویت را انجام می‌دهد؟» را به صورت معنایی و با دقت بالا انجام دهید.
• سیستم‌های Recommendation و Personalization — هر کاربر الگوهای رفتاری خودش را در قالب Embedding ذخیره می‌کند و سیستم پیشنهاددهنده، نزدیک‌ترین همسایگان را با کوئری ساده SQL پیدا می‌کند، بدون خروج از دیتابیس.
• RAG Pipeline با قابلیت فیلتر متادیتا — می‌توانید در یک جدول واحد هم Embedding ذخیره کنید، هم فیلدهای تاریخ، دسته‌بندی، وضعیت و … و سپس جستجوی خود را ترکیبی از فاصله کسینوسی و فیلترهای SQL سنتی انجام دهید. مثلاً: «۵ گفتگوی مرتبط با «مدیریت خطا» که در هفته گذشته ثبت شده‌اند را پیدا کن».
• Local-First و Privacy-Centric AI — در برنامه‌های پزشکی، حقوقی یا مالی که داده‌ها به هیچ وجه نباید از دستگاه کاربر خارج شوند، می‌توانید تمام پایگاه داده RAG را روی دستگاه نگه دارید و در عین حال از قابلیت‌های برداری در کنار داده‌های معمولی بهره ببرید.

۳. لبه (Edge) و همگام‌سازی توزیع‌شده — بدون Cold Start

Turso از طریق پروتکل HTTP و WebSocket به دیتابیس‌ها متصل می‌شود و قابلیت Embedded Replica را دارد: یک دیتابیس اصلی مرکزی، و کپی‌های محلی آن روی سرورهای لبه (Edge) در سراسر جهان مستقر می‌شوند. این کپی‌ها در یک فایل SQLite روی همان سرور لبه ذخیره می‌شوند و خواندن داده از آنها تأخیری حدود $۰٫۸$ میلی‌ثانیه دارد (در مقایسه با $۱۲$ میلی‌ثانیه در یک Postgres ابری معمولی). دیتابیس‌های Turso «فایل» هستند، نه «پردازش»؛ هیچ Cold Start یا Wake-Up Penalty وجود ندارد.

چه موقع از این قابلیت استفاده کنید؟

• اپلیکیشن‌های Serverless روی Cloudflare Workers یا Vercel Edge Functions — این محیط‌ها به پایگاه داده‌ای نیاز دارند که Cold Start نداشته باشد. هر بار که تابع شما اجرا می‌شود، دیتابیس از قبل به عنوان یک فایل در لبه موجود است. هیچ عملکردی برای «بیدار کردن» دیتابیس از حالت خواب وجود ندارد.
• سیستم‌های همگام‌سازی داده در دستگاه‌های غیرمتصل (Offline-First) — می‌توانید یک دیتابیس Turso را روی لپ‌تاپ کاربر یا حتی ربات صنعتی در یک کارخانه ذخیره کنید. در حین قطع اینترنت، تغییرات در فایل دیتابیس محلی ذخیره می‌شوند و هر وقت اتصال برگشت، از طریق پروتکل همگام‌سازی مبتنی بر WAL (Write-Ahead Log) به‌طور خودکار با مرکز هماهنگ می‌شوند.
• کلان‌شهرهای جهانی با کاربران پراکنده — کاربری در استرالیا، اروپا و آمریکای جنوبی همگی می‌توانند از نزدیک‌ترین کپی دیتابیس به خودشان بخوانند و فقط عملیات Write به سرور اصلی (که می‌تواند در region مرکزی انتخاب شود) برود. این باعث می‌شود تأخیر خواندن در همه نقاط جهان زیر $۱۰۰$ میلی‌ثانیه بماند.

۴. نوشتن همزمان با MVCC — پایان خطای SQLITE_BUSY

محدودیت ذاتی SQLite این است که در هر لحظه فقط یک تراکنش می‌تواند بنویسد. Turso با پیاده‌سازی کامل MVCC (Multi-Version Concurrency Control) این محدودیت را از بین برده است. چندین تراکنش می‌توانند به طور همزمان بنویسند، بدون قفل و بدون اینکه نیازی باشد در صف منتظر بمانند. نتایج بنچمارک‌ها نشان می‌دهد سیستم‌های Write-Intensive تا ۴ برابر سریع‌تر از SQLite استاندارد روی Turso اجرا می‌شوند و خطای SQLITE_BUSY به صفر می‌رسد.

چه موقع از این قابلیت استفاده کنید؟

• سیستم‌های جمع‌آوری داده در لحظه (Real-time Ingestion) — جایی که هزاران سنسور یا کاربر همزمان رکوردهای جدید را به دیتابیس می‌فرستند. Turso به جای اینکه ورودی‌ها را در یک صف بزرگ قرار دهد و یکی‌یکی پردازش کند، همه را به صورت همزمان می‌پذیرد.
• پلتفرم‌های همکاری بلادرنگ — مشابه Notion یا Google Docs که چند کاربر همزمان یک سند را ویرایش می‌کنند. هر کاربر می‌تواند تغییرات خودش را همزمان و بدون قفل بنویسد.
• اتوماسیون‌های مبتنی بر رویداد در معماری Event-Driven — چندین ایجنت یا Microservice که به یک Topic مشترک گوش می‌دهند و هرکدام وضعیت خودش را در دیتابیس به‌روز می‌کند؛ بدون تداخل.

یک قدم فراتر: فایل سیستم برای ایجنت‌ها با AgentFS 🤖

تیم Turso پس از دیتابیس، به سراغ نیاز ایجنت‌های هوش مصنوعی به یک فایل سیستم ایزوله رفت: AgentFS.
این لایه فایل سیستم متن‌باز، کاملاً روی دیتابیس Turso پیاده‌سازی شده و یک فضای ذخیره‌سازی ساختاریافته، قابل ممیزی و قابل حمل برای ایجنت‌ها فراهم می‌کند.

همه چیز در AgentFS حول یک فایل SQLite می‌چرخد (شامل یک فایل سیستم مجازی مشابه POSIX، ذخیره‌ساز Key-Value و یک مسیر ممیزی برای دیباگ). از آنجایی که Turso نسخه WebAssembly (WASM) نیز دارد، ایجنت شما حتی در محیط مرورگر هم می‌تواند از ابزارهایی مثل git یا mkdir استفاده کند و تمام تغییرات در یک فایل SQLite ذخیره می‌شود!

خلاصه کلام برای مهندس داده

به عنوان یک مهندس داده، شما به دنبال این هستید که ساده‌ترین معماری ممکن را داشته باشید که:

1. مقیاس‌پذیری افقی داشته باشد — Turso این را با مدل «میلیون‌ها دیتابیس فایل‌محور» تأمین می‌کند.
2. تأخیر پایین در سطح جهانی داشته باشد — Embedded Replicas و Edge-first design این را انجام می‌دهند.
3. هزینه زیرساخت را کاهش دهد — حذف Cold Start و Database-per-User بهینه، هزینه‌ها را تا یک‌سوم کاهش داده است.
4. بدون افزایش پیچیدگی Consistent باشد — همه چیز در یک فایل SQLite با پشتیبانی از MVCC و همگام‌سازی خودکار.

بنابراین دفعه بعد که معماری‌ای برای Agent، RAG Pipeline یا Multi-Tenant App طراحی می‌کنید، به جای این که فکر کنید «به یک Postgres Cluster با Connection Pooler و Redis Cache و یک Vector DB جانبی نیاز داریم»، یک فایل SQLite را در نظر بگیرید که می‌تواند به صورت توزیع‌شده روی لبه‌های جهان اجرا شود و همه این قابلیت‌ها را در خودش داشته باشد.