पिछली वसंत मैं एक SaaS साइड प्रोजेक्ट में तीन हफ्ते में था, Supabase कनेक्ट किया हुआ था, और एक चौराहे पर देख रहा था: Drizzle या Prisma। मैंने Seahawk पर शायद चालीस से अधिक क्लाइंट बिल्ड पर Prisma का उपयोग किया था। आरामदायक क्षेत्र। लेकिन प्रोजेक्ट पर एक जूनियर डेव Drizzle के लिए जोर दे रहा था, और ईमानदारी से मैं शुरुआत में थोड़ा अलग था। "यह नया है। कम सिद्ध। आइए बस Prisma जाएँ।"
मैंने इसे इतनी जल्दी लहराना गलत था।
हम आखिरकार एक ही कोडबेस के विभिन्न भागों पर दोनों को आजमाते हैं (गड़बड़, हाँ, लेकिन शिक्षाप्रद)। जो मैंने सीखा उसने ORM चुनाव के बारे में मेरे सोचने का तरीका पूरी तरह बदल दिया। अगर आप Supabase पर बिल्ड कर रहे हैं और आप वास्तव में अनिश्चित हैं कि कौन सा चुनना है, तो यह वह पोस्ट है जो मेरे पास होना चाहिए।
---
आप वास्तव में किसके बीच चुनाई कर रहे हैं
ये दोनों उपकरण एक ही सतह-स्तरीय समस्या को हल करते हैं: आप हर बार डेटाबेस को छूते समय कच्चा SQL नहीं लिखना चाहते। लेकिन वे बहुत अलग दर्शन से आते हैं।
Prisma आपके स्कीमा को सत्य का एकल स्रोत मानता है। आप एक schema.prisma फाइल परिभाषित करते हैं, prisma generate चलाते हैं, और एक पूरी तरह से टाइप किए गए क्लाइंट को प्राप्त करते हैं। यह SQL को लगभग पूरी तरह से अमूर्त करता है। आप शायद ही कभी तालिकाओं और जॉइन में सोचते हैं; आप मॉडल और संबंधों में सोचते हैं।
Drizzle SQL के बहुत करीब बैठा है। आपका स्कीमा TypeScript में परिभाषित है, आपकी क्वेरीज SQL की तरह लगती हैं, और बीच में कोई अलग CLI-जनरेट किया गया क्लाइंट नहीं है। इसे "TypeScript ORM जो SQL की तरह लगता है" के रूप में वर्णित किया गया है और यह वास्तव में सटीक है।
न तो निष्पक्ष रूप से बेहतर है। पूरी तरह से। विकल्प आपकी टीम, आपकी क्वेरी पैटर्न, और आप Supabase के अपने उपकरण को कितना विश्वास करते हैं, इस पर निर्भर करता है।
---
Supabase संदर्भ सब कुछ बदल देता है
यहाँ वह चीज़ है जो अधिकांश तुलना पोस्ट मिस करते हैं: Supabase एक खाली Postgres डेटाबेस नहीं है। यह Row Level Security, रीयलटाइम सबस्क्रिप्शन, ऑटो-जनरेटेड REST और GraphQL API, और अपना स्वयं का JavaScript क्लाइंट के साथ आता है। आप अक्सर किसी ORM को छूने से पहले भी supabase-js के माध्यम से बहुत कुछ कर रहे होते हैं।
तो असली सवाल सिर्फ "कौन सा ORM बेहतर है?" नहीं है। यह है कि "मेरे क्वेरी लॉजिक का कितना हिस्सा ORM के माध्यम से जाना चाहिए बनाम Supabase क्लाइंट को सीधे?"
मैंने टीमों को देखा है जो Prisma चुनते हैं, supabase-js को लगभग पूरी तरह नजरअंदाज करते हैं, और फिर सोचते हैं कि उनकी RLS पॉलिसीज काम क्यों नहीं कर रही हैं। यह इसलिए है क्योंकि Prisma कनेक्शन स्ट्रिंग के जरिए Postgres से सीधे कनेक्ट करता है। यह Supabase PostgREST लेयर को बायपास करता है। आपकी RLS नियम? केवल तभी लागू होते हैं जब आप Prisma को सेशन स्तर पर SET LOCAL role = authenticated बताएं। इसे सेट अप करना मुश्किल नहीं है, लेकिन आपको यह पता होना चाहिए कि यह एक चीज है।
Drizzle का भी वही मुद्दा है। Postgres का सीधा कनेक्शन, वही बायपास व्यवहार। लेकिन क्योंकि Drizzle ज्यादा SQL-नेटिव लगता है, डेवलपर्स को आमतौर पर ज्यादा पता होता है कि वे कच्चे Postgres से बात कर रहे हैं, Supabase एब्सट्रैक्शन के माध्यम से नहीं।
---
बंडल साइज और कोल्ड स्टार्ट्स: द सर्वरलेस तर्क
अगर आप Vercel Edge Functions, Cloudflare Workers, या यहां तक कि मानक Vercel Serverless Functions में डिप्लॉय कर रहे हैं, तो बंडल साइज एक असली चिंता है।
Prisma का जेनरेटेड क्लाइंट... भारी है। क्वेरी इंजन अकेले एक बाइनरी है जो आपकी डिप्लॉयमेंट के साथ बंडल होती है। कुछ समय के लिए, Vercel पर Prisma डिप्लॉयमेंट 40MB से ज्यादा के बंडल तैयार कर रहे थे। उन्होंने Prisma Accelerate और नए इंजन विकल्पों के साथ इसमें काफी सुधार किया है, लेकिन आप अभी भी वजन की कमी से जूझ रहे हैं। हमने 2023 के अंत में एक Seahawk फिनटेक प्रोजेक्ट पर सर्वरलेस फंक्शन्स पर कोल्ड स्टार्ट्स को ध्यान से देखा। हमने माप किया: Prisma के साथ करीब 800ms कोल्ड स्टार्ट बनाम Drizzle में माइग्रेट करने के बाद 200ms से कम।
Drizzle बहुत छोटा है। जैसे, शर्मनाक तरीके से छोटा। कोई बाइनरी इंजन नहीं। कोई रनटाइम कोड जेनरेशन नहीं। यह न्यूनतम JavaScript में कम्पाइल होता है और आपकी डिप्लॉयमेंट सुस्त रहती है। एज रनटाइम्स के लिए, यह अभी स्पष्ट विकल्प है।
यह कहा जा रहा है, अगर आप एक पारंपरिक Node.js सर्वर (Express, Fastify, एक नियमित VPS पर एक मानक Next.js ऐप) चला रहे हैं, तो यह अंतर बहुत कम मायने रखता है। एक स्थायी कनेक्शन पूल कोल्ड स्टार्ट्स की परवाह नहीं करता।
---
डेवलपर अनुभव: जहां Prisma अभी भी जीतता है
मैं ईमानदार हूं। Prisma का DX को हराना मुश्किल है।
स्कीमा फाइल वास्तव में काम करने के लिए सुखद है। माइग्रेशन्स को prisma migrate dev द्वारा संभाला जाता है और यह काम करता है। Prisma Studio (GUI) ने मुझे Supabase डैशबोर्ड में पोक करने में घंटों बचाए हैं जब मुझे डेटा तेजी से निरीक्षण करने की आवश्यकता होती है। और जेनरेटेड क्लाइंट से आने वाले TypeScript टाइप्स पूर्ण हैं। आपको नेस्टेड रिलेशन्स पर ऑटोकंपलीशन मिलता है, where क्लॉज्स पर, select आकार पर।
Drizzle का TypeScript सपोर्ट भी उत्कृष्ट है, लेकिन इसके लिए अधिक अग्रिम विचार की आवश्यकता है। आप TypeScript फाइलों में अपना स्कीमा लिखते हैं, जो मुझे दार्शनिक रूप से पसंद है। कोई अलग .prisma सिंटैक्स सीखने की जरूरत नहीं। लेकिन क्वेरी बिल्डर को अभ्यास की जरूरत है। जटिल जॉइन्स एग्रीगेट्स जैसी चीजें Prisma के include सिंटैक्स जितनी सहज नहीं हैं।
स्कीमा माइग्रेशन्स: एक असली अंतर
Prisma स्वचालित रूप से माइग्रेशन SQL फाइलें जेनरेट करता है और उन्हें ट्रैक करता है। Drizzle भी करता है, drizzle-kit के साथ, लेकिन वर्कफ्लो थोड़ा अधिक मैनुअल लगता है। आप drizzle-kit generate:pg चलाते हैं, एक SQL फाइल प्राप्त करते हैं, और इसे स्वयं लागू करते हैं (या तेजी से प्रोटोटाइपिंग के लिए drizzle-kit push का उपयोग करें)। कम जादू, अधिक नियंत्रण।
जूनियर डेवलपर्स के लिए, Prisma यहां हर बार जीतता है। सोलो डेवलपर्स के लिए जो यह समझना चाहते हैं कि वास्तव में कौन सा SQL चलाया जा रहा है, Drizzle एक तरीके से संतोषजनक है जो Prisma नहीं है।
---
कच्ची क्वेरी शक्ति और जटिल परिस्थितियां
2019 में एक क्लाइंट ने मुझे एक ब्रीफ दिया जिसमें अत्यंत जटिल एग्रीगेशन की आवश्यकता थी: रनिंग टोटल्स, विंडो फंक्शन्स, कंडीशनल ग्रुपिंग। मैं उस समय Prisma का उपयोग कर रहा था और मैं लगभग तुरंत सीमा तक पहुंच गया। Prisma का queryRaw मौजूद है, लेकिन अन्यथा एब्सट्रैक्टेड कोडबेस में कच्चे SQL में गिरना धोखाधड़ी जैसा लगता है, और आप सभी टाइप सेफ्टी खो देते हैं।
Drizzle इसे बहुत बेहतर संभालता है। विंडो फंक्शन्स, CTEs, लेटरल जॉइन्स: इसके पास उनके लिए या तो फर्स्ट-क्लास बिल्डर है या आप अपने TypeScript कॉन्टेक्स्ट को खोए बिना SQL फ्रैगमेंट्स में गिर सकते हैं। वास्तविक रूप से जटिल रिपोर्टिंग या एनालिटिक्स क्वेरीज वाली Supabase प्रोजेक्ट्स के लिए, Drizzle आपको बढ़ने के लिए अधिक जगह देता है।
यह कहा जा रहा है, 80% CRUD एप्लिकेशन्स को इसमें से कोई नहीं चाहिए। अगर आपकी प्रोजेक्ट "उपयोगकर्ता पोस्ट बनाते हैं, पोस्ट्स में कमेंट्स हैं," तो Prisma के एक्सप्रेसिव रिलेशन क्वेरीज लिखने के लिए तेजी से हैं और अन्य डेवलपर्स के लिए पढ़ने में आसान हैं।
---
हर एक को कब चुनें
मुझे इस बारे में सीधा होने दीजिए, क्योंकि मैंने बहुत सारे लोगों को "उद्देश्यपूर्वक सही" उत्तर खोजने का प्रयास करते हुए देखा है।
Drizzle चुनें अगर:
- आप एज या सर्वरलेस रनटाइम्स में डिप्लॉय कर रहे हैं जहां बंडल साइज और कोल्ड स्टार्ट्स मायने रखते हैं
- आपकी टीम SQL के साथ सहज है और आप यह जानना चाहते हैं कि वास्तविकता में कौन सी क्वेरीज चलाई जा रही हैं
- प्रोजेक्ट में जटिल क्वेरी की आवश्यकताएं हैं (रिपोर्टिंग, एनालिटिक्स, गैर-मानक एग्रीगेशन)
- आप एक सोलो डेवलपर हैं या एक छोटी टीम है जो न्यूनतम एब्सट्रैक्शन ओवरहेड चाहती है
Prisma चुनें अगर:
- आप कनेक्शन पूलिंग के साथ ट्रेडिशनल सर्वर-साइड Node.js सेटअप चला रहे हैं
- आपकी टीम में जूनियर डेवलपर हैं जो गाइडेड स्कीमा-फर्स्ट वर्कफ़्लो से लाभान्वित हो सकते हैं
- प्रोजेक्ट CRUD-हेवी है और रिलेशनल कॉम्प्लेक्सिटी मध्यम है
- आप एक परिपक्व इकोसिस्टम चाहते हैं जिसमें अधिक थर्ड-पार्टी टूलिंग, उदाहरण और Stack Overflow उत्तर हों
एक और चीज जो नाम लायक है: Prisma का डॉक्यूमेंटेशन बेहतर है। काफी हद तक बेहतर। Drizzle के डॉक्स पिछले साल में काफी सुधरे हैं, लेकिन Prisma के पास ट्यूटोरियल, गाइड और कम्युनिटी रिसोर्स बनाने के लिए ज्यादा समय रहा है। अगर आप सीखते जा रहे हैं, तो यह अंतर असली है।
---
Supabase के लिए प्रैक्टिकल सेटअप नोट्स
जो भी आप चुनें, कुछ बातें Supabase से कनेक्ट करते समय सार्वभौमिक रूप से लागू होती हैं।
- कनेक्शन पूलर URI का उपयोग करें, सीधे कनेक्शन का नहीं। Supabase PgBouncer के माध्यम से एक Supabase कनेक्शन पूलर प्रदान करता है। सर्वरलेस के लिए, हमेशा इसका उपयोग करें। सर्वरलेस के लिए Prisma का अनुशंसित
DATABASE_URLपोर्ट 6543 पर पूलर एंडपॉइंट की ओर इशारा करना चाहिए। - PgBouncer का उपयोग करते समय प्रिपेयर्ड स्टेटमेंट को अक्षम करें। Prisma को URL में
?pgbouncer=trueजोड़ा हुआ चाहिए। Drizzle को Postgres.js या node-postgres कॉन्फ़िग मेंprepare: falseसेट करना चाहिए। इसे छोड़ें और आपको प्रोडक्शन में क्रिप्टिक त्रुटियां मिलेंगी। - RLS आपका दोस्त है लेकिन आपको सेशन कॉन्फ़िगर करना होगा। अगर आप चाहते हैं कि RLS पॉलिसीज ORM क्वेरीज पर लागू हों, तो आपको सेशन लेवल पर Postgres रोल और JWT क्लेम सेट करने की जरूरत होगी। यह बॉयलरप्लेट नहीं है जो आपको मुफ्त में मिलता है।
- Supabase की ताकत के साथ लड़ाई न करें। Auth, realtime और storage के लिए
supabase-jsका उपयोग करें। कॉम्प्लेक्स डेटा क्वेरीज के लिए अपने ORM का उपयोग करें जहां Supabase क्लाइंट की फिल्टरिंग कम पड़ जाती है। वे एक ही प्रोजेक्ट में सह-अस्तित्व में रह सकते हैं।
---
FAQ
क्या Drizzle 2024 में प्रोडक्शन-रेडी है?
हां। यह उन कंपनियों की टीमों द्वारा प्रोडक्शन में उपयोग किया जा रहा है जो सिर्फ सप्ताहांत की साइड प्रोजेक्ट नहीं हैं। API देर से 2023 के बाद से गंभीर काम के लिए काफी स्थिर है। मैं अभी भी Prisma को अधिक "बैटल-टेस्टेड" कहूंगा, सिर्फ उम्र की वजह से, लेकिन Drizzle अब एक जोखिम नहीं है।
क्या मैं एक ही प्रोजेक्ट में दोनों का उपयोग कर सकता हूं?
तकनीकी तौर पर हां। हमने यह संक्षेप में किया (गलती से, स्ट्रैटेजी के रूप में नहीं)। न करें। कॉग्निटिव ओवरहेड इसके लायक नहीं है, और दो अलग-अलग माइग्रेशन सिस्टम के एक ही डेटाबेस को छूने से आप बुरे दिन के लिए तैयार हो रहे हैं। एक चुनें।
क्या Prisma Supabase Edge Functions के साथ काम करता है?
Prisma और Supabase Edge Functions (जो Deno पर चलते हैं) का एक जटिल रिश्ता रहा है। Prisma का इंजन Deno में नेटिवली नहीं चलता। Prisma Accelerate या एक एक्सटर्नल पूलिंग सेटअप का उपयोग इसके चारों ओर काम कर सकता है, लेकिन यह अतिरिक्त भागों को जोड़ता है। Drizzle को Deno एनवायरनमेंट में ऐसी कोई समस्या नहीं है।
टाइप सेफ्टी के बारे में क्या? क्या वे तुलनीय हैं?
दोनों TypeScript टाइप जेनरेट करते हैं और दोनों TypeScript प्रोजेक्ट के साथ अच्छी तरह से इंटीग्रेट होते हैं। Drizzle के टाइप आपकी TypeScript स्कीमा डेफिनिशन से निकले होते हैं। Prisma के टाइप जेनरेटेड क्लाइंट से आते हैं। मेरे अनुभव में, Prisma के नेस्टेड रिलेशन टाइप बॉक्स से बाहर थोड़े अधिक ergonomic हैं, लेकिन Drizzle की इनफरेंस काफी हद तक पकड़ में आ गई है।
रनटाइम पर कौन तेज़ है?
Drizzle को एक असली परफॉर्मेंस एज है क्योंकि आपकी क्वेरी और Postgres वायर प्रोटोकॉल के बीच कम रनटाइम ओवरहेड है। बेंचमार्क में, फर्क मापा जा सकता है। अधिकांश असली एप्लिकेशन में यह आपके डेटाबेस के लिए नेटवर्क लेटेंसी से कहीं अधिक है। किसी ORM को मुख्य रूप से raw क्वेरी स्पीड के लिए न चुनें।
---
असली जवाब
Drizzle edge/serverless Supabase प्रोजेक्ट्स के लिए, या कहीं भी जहाँ आप धातु के करीब रहना चाहते हैं। Prisma टीम वाले माहौल, CRUD-भारी ऐप्स, और जहाँ डेवलपर ऑनबोर्डिंग की रफ़्तार मायने रखती है उन स्थितियों के लिए।
मैं अब Drizzle का इस्तेमाल एक साल पहले से ज़्यादा करता हूँ। लेकिन मुझे Prisma के साथ बिताए गए सालों पर कोई अफ़सोस नहीं है। इसने मुझे बेहतर डेवलपर बनाया, कुछ हद तक इसलिए कि यह काफ़ी राय रखने वाला था कि मुझे यह समझना पड़ा कि मैं इसकी सीमाओं से क्यों टकरा रहा हूँ।
न तो कोई आपके प्रोजेक्ट को बनाएगा या तोड़ेगा। आपका स्कीमा डिज़ाइन करेगा। आपके इंडेक्सिंग फ़ैसले करेंगे। वह चुनें जो आपकी टीम के लोगों के लिए सही हो और बनाना शुरू करें।
