او آر ام Prisma 7 در برابر Prisma 8؛ چی عوض شده و چرا اصلا این آپدیت اومد

اگه یه مدت با Prisma کار نکرده باشی، شاید غافلگیر بشی که چقدر سریع همه‌چیز جلو رفته. Prisma 7 نوامبر ۲۰۲۵ منتشر شد و مهم‌ترین ادعاش این بود که کاملاً Rust رو از کلاینت حذف کرده؛ ولی هنوز جوهر اون اعلامیه خشک نشده بود که خود تیم Prisma اعلام کرد یه بازنویسی کامل‌تر به اسم Prisma 8 در راهه. الان توی سپتامبر ۲۰۲۶ هستیم، و Prisma 8 دیگه رسماً نسخه‌ای هست که prisma@latest بهش اشاره می‌کنه — یعنی وقتشه بدونی این دو تا واقعاً چه فرقی با هم دارن.

چرا اصلاً یه نسخه‌ی ۸ لازم شد؟

Prisma 7 یه تغییر معماری بزرگ بود: بایناری‌های Rust که سال‌ها موتور query کلاینت رو تشکیل می‌دادن، حذف شدن و جاشون یه کلاینت خالص جاوااسکریپتی/تایپ‌اسکریپتی اومد. نتیجه‌ش نصب سریع‌تر و deploy ساده‌تر بود، ولی چند تا بنچمارک منتشرشده از کامیونیتی نشون داد که بعضی سناریوها کندتر از Prisma 6 شدن — چیزی که خود تیم Prisma هم پذیرفت و روش کار کرد. یه محدودیت دیگه هم این بود که MongoDB اصلاً توی Prisma 7 پشتیبانی نمی‌شد؛ تلاش برای گسترش همون معماری Rust-free به یه دیتابیس non-SQL مثل MongoDB، پیچیده‌تر و پرریسک‌تر از چیزی بود که تیم بخواد روی همون timeline بریزه.

این محدودیت‌ها باعث شد تیم Prisma به این نتیجه برسه که کدبیس فعلی به سقف توانایی‌هاش رسیده — رفع باگ‌ها کند شده بود و قابلیت‌های جدید دیر به بازار می‌رسیدن. جواب این وضعیت، یه بازنویسی کامل از صفر بود: Prisma 8، این‌بار به‌طور کامل روی تایپ‌اسکریپت، طراحی‌شده از اول برای extensible و composable بودن.

تفاوت مفهومی اصلی: از «کلاینت تولیدشده» به «contract»

توی Prisma 7 و نسخه‌های قبل‌تر، مدل‌ها رو توی یه فایل schema تعریف می‌کردی و Prisma یه کلاینت تولید می‌کرد که ازش import می‌کردی. Prisma 8 این مدل رو عوض کرده: به‌جای تولید یه پکیج کلاینت، schema تبدیل میشه به یه «contract» — یه سند JSON به‌همراه type های تایپ‌اسکریپتی که هم اپلیکیشنت، هم ابزار migration، و هم هر coding agent ای که باهاش کار می‌کنی، همه از همون یه سند می‌خونن. این contract یه artifact عادیه که می‌تونی بازش کنی و diff بگیری ازش، نه یه چیز مخفی پشت پرده.

روی query هم یه DSL ترکیبی (composable) جدید اومده: کوئری‌ها inline و مستقیم روی contract نوشته میشن، و هر کوئری به یه query plan قابل‌بررسی در زمان اجرا کامپایل میشه — یعنی هیچ متد مخفی‌ای داخل کلاینت وجود نداره که رفتارش رو حدس بزنی. کنار این، یه SQL builder سطح‌پایین و type-safe هم برای وقتایی که به کنترل بیشتر نیاز داری اضافه شده.

عملکرد، از نگرانی به مزیت

بعد از انتقاداتی که درباره‌ی performance نسخه‌ی هفت مطرح شد، تیم Prisma روی این مسئله متمرکز کار کرد و نتیجه‌ش توی Prisma 8 دیده میشه: طبق بنچمارک‌های خود تیم، Prisma 8 به حدود ۸۷ درصد throughput خام درایور pg رسیده و ۵۲ درصد request در ثانیه بیشتر از Prisma 7 داره. اگه از Prisma 7 به این دلیل ناامید شده بودی که کندتر از انتظارت بود، این عدد دلیل خوبیه که دوباره بهش نگاه کنی.

migration و ابزارها

فرآیند migration هم توی Prisma 8 بازطراحی شده: مفاهیمی مثل migration graph، ویرایش مستقیم یه migration، و rollback و recovery رسمی‌تر و شفاف‌تر شدن. یه سیستم middleware داخلی هم اضافه شده که budget (محدودیت اجرای query)، lint، و cache رو به‌صورت built-in پشتیبانی می‌کنه، به‌جای اینکه هرکسی این‌ها رو با کتابخونه‌های جداگانه پیاده کنه. ایندکس‌های expression، partial و unique هم حالا هم توی Prisma Schema Language و هم توی تایپ‌اسکریپت قابل تعریف هستن، و Prisma 8 می‌تونه ایندکس‌ها و سیاست‌های row-level security یه دیتابیس موجود رو مستقیم بخونه.

خبر MongoDB هم بالاخره روشن شده: تیم Prisma رسماً اعلام کرده پشتیبانی از MongoDB از این به بعد فقط از طریق Prisma 8 میاد، نه Prisma 7 — یعنی اگه منتظر MongoDB روی نسخه‌ی هفت بودی، دیگه نباید منتظرش بمونی.

می‌تونی نسخه‌ی هفت و هشت رو کنار هم اجرا کنی

یکی از تصمیم‌های هوشمندانه‌ی تیم Prisma این بوده که مسیر مهاجرت رو تدریجی طراحی کنن: می‌تونی Prisma 7 و Prisma 8 رو توی یه پروژه‌ی واحد، کنار هم و ماژول‌به‌ماژول اجرا کنی. مثلاً بخشی از route هات از کلاینت Prisma 7 استفاده کنن و بخش دیگه از Prisma 8، در حالی که هر دو روی یه schema دیتابیس مشترک کار می‌کنن؛ فقط باید مشخص کنی کدوم نسخه مالک migration هاست. این یعنی مجبور نیستی یه‌شبه کل پروژه رو آپدیت کنی.

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

با اینکه prisma@latest الان به Prisma 8 اشاره می‌کنه و Prisma Compute هم به مرحله‌ی production با قیمت‌گذاری رسمی رسیده، بخشی از تغییرات هنوز داره توی همون بازه‌ی release candidate جا میفته و ممکنه بین نسخه‌ها breaking change ببینی — مثلاً تغییر اسم فایل کانفیگ، یکپارچه شدن دستورهای CLI، یا تغییر نام متدهای pagination. اگه پروژه‌ات production حساسه، منطقی‌تر اینه که فعلاً روی Prisma 7 بمونی؛ تیم Prisma هم رسماً قول داده که Prisma 7 حداقل تا یک سال دیگه support کامل داشته باشه. اگه پروژه‌ی جدید شروع می‌کنی یا حاضری با یه سری تغییرات جزئی بین نسخه‌ها کنار بیای، Prisma 8 الان یه انتخاب معقول و رو به جلوئه، مخصوصاً اگه معماری contract-based و بهبود performance براتون مهمه.

جمع‌بندی کوتاه: Prisma 7 یه تغییر معماری بزرگ بود (حذف Rust)، Prisma 8 یه بازنویسی کامل‌تره که مدل داده رو از «کلاینت تولیدشده» به «contract قابل بازرسی» تبدیل می‌کنه، performance رو به‌طور محسوس بهتر کرده، و راه رو برای MongoDB و قابلیت‌های جدیدتر باز کرده. انتخاب بین این دو، بیشتر به این برمی‌گرده که چقدر برای تغییرات هنوز در حال تثبیت شدن، آماده‌ای.