پایگاه دادهها به لبه حرکت میکنند — Turso، Neon و Cloudflare D1 محل زندگی دادههای شما را بازنویسی میکنند
برای بیشتر تاریخ پایگاه دادهها، پاسخ به این سؤال که پایگاه داده شما کجا زندگی میکند ساده بود: در یک مرکز داده، احتمالاً یک یا دو منطقه برای افزونگی، قابل دسترسی برای سرورهای برنامه شما از طریق یک شبکه خصوصی سریع. پایگاه داده مرکز است. همه چیز به آن متصل میشود. تأخیر بین برنامه و پایگاه داده شما با پرشهای شبکه زیر میلیثانیه در همان مرکز اندازهگیری میشود.
مشکل این مدل این است که مکان کاربران را در نظر نمیگیرد. اگر سرورهای برنامه شما در us-east-1 باشند و کاربری در سنگاپور درخواستی ارسال کند، آن درخواست از سنگاپور به ویرجینیا و بازمیگردد — حدود ۲۰۰ میلیثانیه تأخیر رفت و برگشت قبل از اینکه حتی به پرسوجوهای پایگاه داده فکر کنید. پلتفرمهای مدرن Serverless و Edge Runtimes کد برنامه را به کاربران نزدیکتر کردهاند: Cloudflare Workers در بیش از ۳۰۰ مکان اجرا میشود، Vercel Edge Functions در دهها منطقه مستقر میشوند. اما بیشتر برنامهها هنوز یک نمونه Postgres یا MySQL واحد را که در یک منطقه نشسته است پرسوجو میکنند و مزیت تأخیر اجرای Edge را در لحظه فراخوانی پایگاه داده از بین میبرند.
پایگاه دادههای Edge سعی میکنند این مشکل را با جابهجایی خود داده — یا حداقل دادههای پراستفاده — به نزدیکتر کاربران حل کنند.
رقبای اصلی
Turso بر روی libSQL ساخته شده است، یک Fork از SQLite با قابلیت Replication اضافه شده. معماری ساده است: یک پایگاه داده اصلی نسخه معتبر دادههای شما را ذخیره میکند و Turso به طور خودکار آن را به مکانهای Edge نزدیک کاربران شما Replicate میکند. خواندن به نزدیکترین Replica برخورد میکند؛ نوشتن به اصلی میرود. Turso Replicaهای Edge را در دهها منطقه مستقر کرده و همه چیز را از دید توسعهدهنده مانند یک اتصال استاندارد SQLite نشان میدهد. مدل قیمتگذاری تهاجمی است — یک سطح رایگان سخاوتمندانه، سپس قیمتگذاری به ازای هر پایگاه داده. برای برنامههایی با Tenantهای منزوی زیاد (محصولات SaaS که هر مشتری پایگاه داده خود را دارد)، مدل Turso قانعکننده است: میتوانید هزاران پایگاه داده با هزینه بسیار کم داشته باشید که هرکدام در نزدیکی کاربر اصلی خود قرار دارند.
Neon رویکرد متفاوتی دارد: Postgres Serverless است، با ذخیرهسازی و محاسبه جداگانه. محاسبه در صورت عدم استفاده به صفر کاهش مییابد (هزینههای بیکاری را حذف میکند) و در عرض چند ثانیه با رسیدن ترافیک افزایش مییابد. لایه ذخیرهسازی بادوام، چند Tenant و در سطح Block به صورت جهانی Replicate میشود. Replicaهای خواندنی میتوانند در هر منطقه مستقر شوند. تجربه توسعهدهنده بسیار نزدیک به Postgres استاندارد است — رشتههای اتصال، psql، همه ابزارهای معمول کار میکنند — که اصطکاک مهاجرت را به طور قابل توجهی کاهش میدهد. ویژگی Branching در Neon، که Snapshotهای آنی Copy-on-Write از پایگاه داده شما برای توسعه یا آزمایش ایجاد میکند، به طور گسترده تحسین شده است.
Cloudflare D1 نیز مبتنی بر SQLite است و عمیقاً با Cloudflare Workers یکپارچه شده است. ایده ساده است: اسکریپت Worker شما در Edge اجرا میشود و D1 درست در کنار آن قرار دارد. برای پرسوجوهایی که نیاز به سازگاری جهانی ندارند، D1 رفت و برگشت به یک پایگاه داده مرکزی را کاملاً حذف میکند. D1 در حال حاضر از نظر ویژگیها در مقایسه با یک Postgres کامل محدود است — بدون پشتیبانی از کلید خارجی به صورت پیشفرض، محدود به سیستم نوع SQLite — اما برای خواندن زمانی که با Edge Worker رسیدگیکننده به درخواست هممکان است، واقعاً سریع است.
PlanetScale به دلیل دیگری شایسته ذکر است: در سال ۲۰۲۴ اعلام کرد که سطح رایگان خود را پایان میدهد و دوباره روی مشتریان سازمانی تمرکز میکند. چندین توسعهدهنده که پروژههایی را بر روی سرویس سازگار با MySQL PlanetScale ساخته بودند برای مهاجرت دست به کار شدند و بسیاری به Neon یا Turso رفتند. معماری مبتنی بر Vitess PlanetScale مقیاسپذیری افقی را با قیمتی ارائه میداد که ناپایدار بود. این رویداد یادآوری مفیدی بود که سرویسهای پایگاه داده رایگان یک پایه تضمینشده نیستند.
مشکل سازگاری
پایگاه دادههای Edge یک مصالحه واقعی انجام میدهند: توزیع داده برای خواندن با تأخیر کم باعث میشود سازگاری قوی دشوارتر شود. این مشکل جدیدی نیست — قضیه CAP برای دو دهه جزء ثابت آموزش سیستمهای توزیعشده بوده است — اما در طراحی پایگاه دادههای Edge به روشهایی قابل درک ملموس میشود.
با Replicaهای Edge در Turso، یک نوشتن که در اصلی ثبت شده است ممکن است چند صد میلیثانیه طول بکشد تا به همه Replicaهای Edge منتشر شود. اگر کاربری دادهها را بنویسد و بلافاصله آن را بخواند و خواندن به Replicaای برخورد کند که هنوز نوشتن را دریافت نکرده است، دادههای قدیمی میبیند. برای بسیاری از برنامهها — یک وبلاگ، یک کاتالوگ محصول، یک فید اجتماعی — این قابل قبول است. برای برنامههایی که سازگاری حیاتی است — یک تراکنش مالی، یک بهروزرسانی موجودی با محدودیتهای سخت — قابل قبول نیست.
Neon این موضوع را متفاوت مدیریت میکند. Replicaهای خواندنی آن میتوانند به صورت Synchronous (سازگار تضمینشده) یا Asynchronous (تأخیر کمتر، احتمالاً قدیمی) پیکربندی شوند. بیشتر برنامهها میتوانند از Replicaهای Asynchronous برای مسیرهای پرخواندن استفاده کنند و نوشتنها و خواندنهای حساس به تأخیر را به اصلی هدایت کنند. معماری از Turso انعطافپذیرتر است اما نیازمند تفکر صریحتر در مورد اینکه کدام پرسوجو به کدام سطح سازگاری نیاز دارد.
مدل سازگاری Cloudflare D1 به یک منطقه محدود میشود: نوشتنها به D1 بلافاصله برای خواندن در همان منطقه قابل مشاهده است، اما سازگاری جهانی تضمین نمیشود. Durable Objects Cloudflare یک Primitiv متفاوت برای حالت سازگار جهانی فراهم میکند، اما Durable Objects یک پایگاه داده رابطهای نیستند.
همگرایی به سمت SQLite
یک الگوی قابل توجه در چشمانداز پایگاه دادههای Edge این است که چقدر از این محصولات روی SQLite به عنوان موتور ذخیرهسازی زیربنایی خود همگرا میشوند. libSQL Turso، Cloudflare D1، پایگاه داده داخلی Bun، و چندین مورد دیگر همگی از SQLite یا یک مشتق استفاده میکنند. دلایل عملی هستند: SQLite برای بارهای کاری تکنویسنده بسیار سریع است، در فرآیند برنامه جاسازی شده (بدون سرور جداگانه) است و به طور فوقالعادهای آزمایش شده است. چالش همیشه Replication بوده است که SQLite استاندارد از آن پشتیبانی نمیکند — libSQL، LiteFS و پروژههای مشابه در حال کار برای پر کردن این شکاف هستند.
ظهور SQLite به عنوان یک موتور پایگاه داده تولیدی جدی — فراتر از نقش سنتی آن به عنوان یک ذخیره محلی جاسازیشده — یکی از جالبترین روندهای زیرساخت در چند سال اخیر است. روی همه چیز از دستگاههای IoT تا توابع Serverless Edge اجرا میشود و سادگی آن به طور فزایندهای یک ویژگی است تا یک محدودیت.
چه زمانی استفاده کنیم
پایگاه دادههای Edge برای برنامههایی مناسب هستند که کاربران به صورت جهانی توزیع شدهاند، بارهای کاری پرخواندن معمول است و سازگاری نهایی برای بیشتر پرسوجوها قابل قبول است. محصولات SaaS با پایگاه دادههای جداگانه برای هر Tenant، پلتفرمهای محتوا با مخاطبان جهانی، و Backendهای API که به برنامههای موبایل در مناطق جغرافیایی زیادی سرویس میدهند، همه نامزدهای معقولی هستند.
آنها برای برنامههای با تراکنشهای پیچیده، نیازمندیهای سازگاری سخت در میان کاربران زیاد، یا بارهای کاری تحلیلی سنگین، تناسب کمتری دارند. یک دفتر کل مالی، یک سیستم موجودی تجارت الکترونیک تحت نوشتنهای همزمان زیاد، یا یک انبار داده باید احتمالاً روی یک پایگاه داده متمرکز معمولی باقی بمانند — حداقل تا زمانی که اکوسیستم پایگاه داده Edge بیشتر بالغ شود.
فشار زیربنایی که این تغییر را هدایت میکند از بین نمیرود: کاربران برنامههای سریع انتظار دارند و برنامههای سریع به دادههای نزدیک به کاربران نیاز دارند. دسته پایگاه دادههای Edge هنوز جوان است، ابزارها از Postgres متمرکز کمتر بالغ هستند و برخی لبههای ناهموار باقی ماندهاند. اما برای بار کاری مناسب، بهبود تأخیر ملموس و واقعی است — و این معمولاً نحوه شروع پذیرش زیرساخت است.