Drizzle وقتی SQL را می‌خواهی؛ Prisma وقتی Client را می‌خواهی

برای اپ Next.js با App Router و Postgres، انتخاب بین Drizzle ORM و Prisma ORM انتخاب قبیله نیست. انتخاب شکل لایه داده است. یا کوئری باید شبیه SQL با تایپ باشد، یا شبیه Client تولیدشده با schema جدا. بنچمارک را تا وقتی دردناک‌ترین کوئری سال بعد را نام نبرده‌ای جدی نگیر.

انتخاب غلط دو چهره دارد. یا SQL تولیدشده‌ای که موقع حادثه نمی‌توانی توضیحش بدهی، یا هفته‌ها join دستی برای چیزی که یک نوشتن تو در تو در Client برایت جمع می‌کرد. هر دو هزینه واقعی‌اند. فقط به آدم‌های مختلف اصابت می‌کنند.

هر ابزار مالک چیست

Drizzle کد-اول است. schema را در TypeScript می‌نویسی. کوئری شکل `select` و `from` و `where` و `join` دارد. یک Client غول‌پیکر جدا تولید نمی‌شود. مهاجرت SQL است و می‌شود در بازبینی کد خواندش. درایور را خودت وصل می‌کنی، چه `node-postgres`، چه `postgres.js`، چه درایور مناسب محیط serverless. اندازه استخر، تراکنش، و مرز prepare جلوی چشم می‌ماند.

Prisma schema-اول است. مدل را در `schema.prisma` می‌نویسی، Client تولید می‌شود، و با `findMany` و `create` و رابطه تو در تو کار می‌کنی. مهاجرت با Prisma Migrate پیش می‌رود و برای اسپایک اولیه `db push` هم هست. Prisma Studio به آدم غیرفنی یک پنجره روی ردیف‌ها می‌دهد. در Prisma 7 اعتراض قدیمی «همه‌جا موتور Rust» دیگر محور تصمیم نیست. مسیر فعلی آداپتور درایور است، مثل `@prisma/adapter-pg`، با Node به‌روز، و اتصال به‌صورت آداپتور و استخر نه باینری جادویی. پرچم‌های قدیمی مربوط به موتور را از روی عادت وبلاگ‌های کهنه کپی نکن.

Drizzle را وقتی انتخاب کن که SQL مهارت محصول است

تیم `EXPLAIN` را می‌خواند و از join نمی‌ترسد. schema باید کنار اپ در TypeScript بماند و هر ویرایش منتظر یک تولید مجدد سنگین نباشد. گزارش، CTE، و ایندکس جزئی را خودتان می‌نویسید نه اینکه از API تقریبی‌اش کنید. اندازه باندل برای Worker یا مسیرهای خیلی کوچک مهم است. و قبول داری استخر اتصال در Server Component و Route Handler مال خودت باشد.

روی App Router، Drizzle خوب می‌نشیند: یک singleton برای دیتابیس، کوئری تایپ‌دار، داده ساده برمی‌گردد. قانون اتصال را خودش اختراع نمی‌کند و قایمش هم نمی‌کند. به ازای هر رندر یک اتصال TCP تازه باز نکن. یک استخر در هر فرآیند، و تراکنش کوتاه.

هزینه را پنهان نکن. نفر تازه‌کار کندتر راه می‌افتد. «کاربر با پروفایل و سه صندلی» بیشتر از یک فراخوانی تو در تو کد می‌خواهد. Studio رایگان نداری. اگر پشتیبانی با کلیک روی رابطه دیباگ می‌کند، ابزار دیگری را در بودجه بگذار.

Prisma را وقتی انتخاب کن که Client مهارت محصول است

تیم سطح‌های مختلف دارد و با Client تولیدشده سریع‌تر از تسلط به SQL تحویل می‌دهد. شکل غالب mutation نوشتن تو در تو و `include` است. Studio یا مدل ذهنی آن بخشی از دیباگ داده است. یا امروز schemaی Prisma داری که محصول روی آن پول درمی‌آورد؛ در این حالت ارتقا به Prisma 7 معمولاً عاقلانه‌تر از بازنویسی ضرب‌الاجلی روی Drizzle است.

موتورهایی غیر از Postgres هم اگر در نقشه واقعی تو هستند، در این تصمیم وزن دارند. اگر فقط Postgres داری، این بند را به‌خاطر آینده خیالی وارد رأی نکن.

در App Router، Client را پشت Server Component، Route Handler، یا Server Action نگه دار. وارد Client Component نکن. جایی که میزبان URL استخر و URL مستقیم را جدا کرده، ترافیک اجرا از URL استخر برود و مهاجرت از مسیر مستقیم. این الگوی Neon و Supabase و میزبان‌های مشابه است. با Prisma 7 آداپتور را یک‌جا تنظیم کن.

هزینه این طرف هم واقعی است. SQL نامعمول از `$queryRaw` نشت می‌کند. اگر هر ویژگی یک CTE تازه می‌خواهد، API با تو می‌جنگد. Client تولیدشده و گردش مهاجرت را باید راه ببری، حتی اگر داستان باندل نسبت به نسل‌های قبل بهتر شده باشد.

چیزی که در App Router رأی را عوض می‌کند

هر دو می‌توانند خواندن کوتاه برای Server Component انجام دهند. تفاوت وقتی است که سؤال محصول این شکل را بگیرد: کاربرانی که دو بار پرداخت ناموفق داشته‌اند، وصل به ردیف فاکتور، بدون حساب تست. در Drizzle همان join را می‌نویسی. در Prisma ترکیبی از `select` و `include` و گاهی خام. اگر این شکل سؤال هفتگی است، به ابزاری رأی بده که همان جا شفاف است.

کش Next.js جای ایندکس را نمی‌گیرد. هر دو ORM اگر رابطه را بی‌محابا بار کنند، صفحه را چاق می‌کنند. شکل کوئری را جدا از برند ORM حساب کن. اتصال را هم همین‌طور. محیط serverless اگر به ازای هر نمونه سرد اتصال تازه بسازد، هم Drizzle غافل هم Prisma غافل به سقف استخر می‌خورند.

مهاجرت را در بازبینی انسان نگه دار. SQL قابل خواندن در Drizzle این را راحت می‌کند. در Prisma خروجی Migrate را همان‌قدر جدی بخوان. تولید خودکار عذر نخواندن نیست.

تصمیم را این‌طور بنویس

اگر بیشتر کوئری‌های هسته باید در حادثه مثل SQL خوانده شوند و تیم این سواد را دارد یا حاضر است بسازد، Drizzle. اگر سرعت تیم به Client و نوشتن تو در تو و ابزار مشاهده ردیف بند است، Prisma، و اگر از قبل Prisma داری اول مسیر Prisma 7 را حساب کن نه بازنویسی.

هر دو را در یک دامنه کوچک قاطی نکن. دو لایه داده برای یک Postgres یعنی دو جور تراکنش، دو جور مهاجرت، و هیچ‌کس که در حادثه مطمئن باشد کدام مسیر نوشته. اگر استثناء خام لازم شد، همان را در گوشه مشخص بگذار و اسمش را لایه دوم نگذار.

پرسش‌های کوتاه

برای پروژه تازه تک‌نفره کدام؟ اگر خودت SQL را دوست داری Drizzle مسیر کوتاه‌تری به حقیقت دیتابیس است. اگر می‌خواهی زودتر CRUD تو در تو داشته باشی و schema جدا برایت روشن است، Prisma.

می‌شود بعداً عوض کرد؟ می‌شود و گران است، چون شکل کوئری به ذهن تیم چسبیده. برای همین کوئری دردناک سال بعد را همین حالا نام ببر.

ORM را کنار بگذارم و SQL خام بنویسم؟ برای بخش گزارش گاهی بهترین کار است. برای کل اپ فقط اگر تیم واقعاً حاضر باشد نگاشت و مهاجرت را خودش مالک شود.