‏برنچ‌گرفتن از دیتابیس؛ هر توسعه‌دهنده دیتابیس خودش رو داره

این مقاله‌ی Databricks با یه نکته‌ی تاریخی شروع می‌کنه: متدولوژیِ Evolutionary Database Design بیست سال پیش روشن شد — هفت اصل، کاتالوگ بیش از ۷۰ refactoring نام‌دار، و مکانیک گذار، همه مستند و آموزش‌داده‌شده. این روش در ۲۰۱۰ با کتاب Continuous Delivery به CI/CD رسید و migrationها به آرتیفکت‌های درجه‌یک خط‌لوله تبدیل شدن. ولی یه چیز حل نشد: ایزولاسیون per-pipeline. اصل چهارم یعنی «هر کس یه نمونه‌ی دیتابیس خودش رو داره» روی بیشتر تیم‌ها آرزو موند، چون دیتابیسِ واقعیِ شبیه‌تولید برای هر توسعه‌دهنده هزینه و وقت و چرخه‌ی DBA می‌خواد. لایه‌ی جبرانی‌ای که شکل گرفت (mock، استیجینگ مشترک، دیتابیس درون‌حافظه، صف تیکت DBA) به‌جای انتخاب آگاهانه، عملاً تبدیل به متدولوژی پیش‌فرض شد.

حالا در ۲۰۲۶، برنچ‌گرفتن copy-on-write به Databricks Lakebase اومده: یه برنچِ یک‌ثانیه‌ای و بدون مصرف فضا هنگام ساخت از یه دیتابیس تولیدیِ ترابایتی، که یه عملیات O(1) شده. همون قیدی که اصل چهارم رو آرزو نگه داشته بود، برداشته شده.

مقاله این تغییر رو با داستان توسعه‌دهنده‌ای به اسم Jen (شخصیتِ همون مقاله‌ی اصلیِ بیست‌سال پیش) نشون می‌ده. Jen یه فیچر به‌ظاهر ساده برمی‌داره: شکستن یه فیلد به سه ستون location، batch و serial. ولی با دیتابیس مشترک، کار سخت می‌شه: باید منتظر بمونه تا دیتابیس آزاد بشه، با بقیه هماهنگ کنه که کی migration بزنه، یا به یه Postgres محلی با داده‌ی هفته‌ی پیش یا یه دیتابیس درون‌حافظه‌ی H2/SQLite با dialect اشتباه پناه ببره — که تست‌ها محلی پاس می‌شن ولی روی Postgres واقعی می‌شکنن. مشکل واقعیِ او بازخورد کند است.

با برنچ دیتابیس در Lakebase، Jen یه دستور می‌زنه (databricks postgres create-branch) و یه فضای ایزوله از همون موتور Postgres، همون اسکیما، همون سیاست‌های حاکمیتی و همون داده‌ی شبیه‌تولید می‌گیره؛ با این تفاوت که می‌تونه تغییرش بده، دور بندازه یا دوباره بسازه بدون اینکه روی کار کسی اثر بذاره. حالا می‌تونه چند طراحی مختلف رو امتحان کنه، migration رو با flyway migrate در کمتر از یک ثانیه روی داده‌ی واقعی اجرا کنه و تست‌ها رو بدون mock روی Postgres واقعی بزنه. اگه خواست از نو شروع کنه، برنچ رو دور می‌ندازه و یه برنچ تازه از تولید می‌سازه — یه ثانیه‌ی دیگه، بدون تیکت پاکسازی، بدون دخالت DBA.

این کار review رو هم عوض می‌کنه. وقتی Jen یه PR باز می‌کنه، CI همون کار رو برای تیم انجام می‌ده: یه برنچ موقت می‌سازه، migration رو اعمال می‌کنه، تست‌ها رو می‌زنه، migration رو اعتبارسنجی می‌کنه و یه کامنت schema-diff روی PR می‌ذاره. در نتیجه سؤال review از «این دیتابیس رو خراب می‌کنه؟» به «این طراحیِ درستیه؟» تغییر می‌کنه و DBA به‌جای یه دروازه‌بانِ آخرِ کار، به یه شریکِ طراحی در همون اول مسیر تبدیل می‌شه.

نکات کلیدی:

• برنچ‌گرفتن copy-on-write در Lakebase کپیِ یک‌ثانیه‌ای و بدون‌فضا از دیتابیس ترابایتی رو ممکن کرده
• این اصلِ بیست‌ساله‌ی «هر کس دیتابیس خودش رو داره» رو بالاخره عملی می‌کنه
• دیتابیس مشترک یعنی انتظار، هماهنگی و ترس؛ برنچ یعنی فضای ایزوله با داده‌ی شبیه‌تولید و آزمایش ارزون
• review از «این دیتابیس رو خراب می‌کنه؟» به «این طراحیِ درستیه؟» تغییر می‌کنه و DBA شریک طراحی می‌شه