ধীর Prisma কুয়েরি ঠিক করুন সরাসরি SQL এক্সিকিউশনের মাধ্যমে

Prisma-এর DX পছন্দ, কিন্তু সমর্থিত কুয়েরি শেপে রিডের ওভারহেড কমাতে চান? বর্তমান বেঞ্চমার্ক JSON Prisma v6, v7 ও v8 জুড়ে গড় গতিবৃদ্ধি দেখায় সমর্থিত PostgreSQL ও SQLite রিডের ক্ষেত্রে; আলাদা আলাদা কুয়েরি শেপে ফল ভিন্ন হয়।

এখনই Prisma দ্রুত করুন

  • সমর্থিত রিড আরও দ্রুত
  • কুয়েরি বদলাতে হয় না
  • বর্তমান বেঞ্চমার্ক JSON
  • PostgreSQL ও SQLite
আপনার Prisma কলuser.findMany
const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true },
})
prisma-sql যে SQL চালায়
SELECT user_t.id, user_t.email, user_t.status,  COALESCE((    SELECT COALESCE(json_agg(json_build_object(      'id', posts_0.id,      'title', posts_0.title,      'authorId', posts_0."authorId"    )), '[]'::json)    FROM "public"."Post" posts_0    WHERE posts_0."authorId" = user_t.id  ), '[]'::json) AS postsFROM "public"."User" user_tWHERE user_t.status = $1
প্যারামিটার ["ACTIVE"]1টি স্টেটমেন্ট
দুই মডেলের একটি স্কিমার জন্য createToSQL-এর আউটপুট, লাইন ব্রেক যোগ করা হয়েছে।
Prisma কভারেজ
v6–v8
PostgreSQL ও SQLite বেঞ্চমার্ক ম্যাট্রিক্স
কুয়েরি পরিবর্তন
0
আপনার বিদ্যমান Prisma কল রেখে দিন
বেঞ্চমার্ক ফাইল
6
Prisma v6/v7/v8 × PG/SQLite
টাইপ সেফটি
100%
একই Prisma API

Prisma কেন ধীর?

Prisma-এর বিবর্তন ও পারফরম্যান্সের বৈশিষ্ট্য বুঝলে বোঝা যায় এই এক্সটেনশন কেন আছে।

Prisma-এর যাত্রা: আগে DX, স্কেলে পারফরম্যান্স গুরুত্বপূর্ণ

💡 এই এক্সটেনশন কেন আছে

Prisma তার লক্ষ্যের জন্য সঠিক আর্কিটেকচারগত সিদ্ধান্ত নিয়েছে: টাইপ সেফটি, ডেভেলপার এক্সপেরিয়েন্স এবং বিভিন্ন ডেটাবেসে একই আচরণ। কিন্তু এই সিদ্ধান্তগুলো এমন ওভারহেড তৈরি করে যা স্কেলে চোখে পড়ে। এই এক্সটেনশন Prisma-কে প্রতিস্থাপন করে না—যে টিমগুলো Prisma-এর DX রাখতে চায় এবং যেখানে দরকার সেখানে দ্রুত এক্সিকিউশন চায়, তাদের জন্য এটি রিড অপটিমাইজ করে।

  1. 🎯 2019: আধুনিক Prisma-এর জন্ম

    Prisma 2 চালু হয় 2019 সালে। টাইপ-সেফ ডেটাবেস অ্যাক্সেস এবং স্কিমা থেকে জেনারেট হওয়া টাইপ দিয়ে এটি TypeScript ORM-এর জগৎ বদলে দেয়। কুয়েরি অনুবাদ ও যাচাই করতে এবং প্রচলিত JavaScript ORM-এ যা পাওয়া কঠিন ছিল এমন শক্ত নিশ্চয়তা দিতে Prisma একটি ইঞ্জিন-ভিত্তিক আর্কিটেকচার আনে।

  2. ⚡ 2020–2022: দ্রুত বৃদ্ধি ও ফিচার বিস্তার

    Prisma নেস্টেড রাইট, ট্রানজ্যাকশন ও মিডলওয়্যারের মতো শক্তিশালী ফিচার যোগ করে। ফিচার বাড়ে, কিন্তু প্রতিটি কুয়েরিকে তখনও একটি আর্কিটেকচারগত খরচ দিতে হয়: কুয়েরি উপস্থাপন, যাচাই ও এক্সিকিউট করা হয়, আর ফলাফলকে Prisma API-এর সাথে মিলিয়ে গঠন করা হয়।

  3. 📊 2023: স্কেলে ওভারহেড চোখে পড়তে থাকে

    আরও বেশি টিম উচ্চ-ট্রাফিক ওয়ার্কলোডে Prisma ডিপ্লয় করায় প্রতি কুয়েরির নির্দিষ্ট ওভারহেড পরিমাপযোগ্য হয়ে ওঠে। রিড-প্রধান এন্ডপয়েন্ট, অ্যানালিটিক্স, অ্যাগ্রিগেশন এবং বড় রেজাল্ট সেটে এটি সবচেয়ে বেশি দেখা যায়। এই ওভারহেড কোনো বাগ নয়; এটি Prisma-এর নিশ্চয়তা ও API আচরণের খরচ।

  4. 🚀 2024–2025: Prisma-এর পারফরম্যান্সের কাজ চলছে

    Prisma পারফরম্যান্স ও ইঞ্জিন পরিবর্তনকে কেন্দ্র করে বড় আপডেট প্রকাশ করে। উন্নতির পরও সরাসরি raw SQL চালানোর তুলনায় পার্সিং, যাচাই, পরিকল্পনা ও ফলাফল গঠনের একটি অনিবার্য খরচ থেকে যায়।

  5. 🎯 2026: prisma-sql এক্সটেনশন প্রকাশিত

    এই এক্সটেনশন রিড পারফরম্যান্সে মনোযোগ দেয়। findMany, findFirst, findUnique, count, aggregate ও groupBy-এর জন্য এটি Prisma-এর রিড এক্সিকিউশন পথ এড়িয়ে যায়, আর রাইট, মাইগ্রেশন, স্কিমা ব্যবস্থাপনা ও টাইপ জেনারেশনের জন্য Prisma-ই থাকে। রোলআউটের আগে আপনার Prisma ভার্সনের সাথে সামঞ্জস্য যাচাই করুন।

কুয়েরি অনুবাদের স্তর

Prisma আপনার কুয়েরি ইনপুটকে ডেটাবেস-নির্দিষ্ট SQL-এ অনুবাদ করে। এতে বিভিন্ন ডেটাবেসে একই আচরণ ও Prisma-এর API সেমান্টিক্স পাওয়া যায়, কিন্তু ডেটাবেস SQL পাওয়ার আগে প্রসেসিংয়ের সময় বাড়ে।

যাচাই ও টাইপের নিশ্চয়তা

Prisma স্কিমার সাথে মিলিয়ে কুয়েরি যাচাই করে এবং API-স্তরের নিশ্চয়তা বজায় রাখে। এই সুরক্ষাগুলো নির্দিষ্ট ধরনের বাগ প্রতিরোধ করে, কিন্তু প্রতিটি কুয়েরিতে ওভারহেডও যোগ করে।

ফলাফল গঠন

ফলাফলকে Prisma-এর API আচরণের সাথে মিলিয়ে গঠন করা হয়। DX ও সামঞ্জস্যের জন্য এটি চমৎকার, কিন্তু ল্যাটেন্সি বাড়ায়, বিশেষ করে বড় রেজাল্ট সেট ও জটিল include-এ।

সমর্থিত রিড কুয়েরির জন্য একটি দ্রুততর পথ দিয়ে এই এক্সটেনশন Prisma-এর পরিপূরক হিসেবে কাজ করে। স্কিমা, মাইগ্রেশন, রাইট ও জেনারেট হওয়া টাইপের জন্য Prisma থাকে, আর বাছাই করা ঘন ঘন চলা রিডগুলো ডেটাবেস-নেটিভ ক্লায়েন্টের মাধ্যমে জেনারেট হওয়া SQL দিয়ে চলে।

কতটা দ্রুত? বাস্তব বেঞ্চমার্ক

Prisma v6, v7, v8, Drizzle ORM ও prisma-sql জুড়ে সর্বশেষ বেঞ্চমার্ক JSON-এর তুলনা

PostgreSQL

প্রতি রানে 95টি কুয়েরি কেস
  • Prisma v6 (6.19.3)Drizzle-এর তুলনায় 1.56×
    1.99×

    Prisma v6 (6.19.3): Prisma-এর তুলনায় গড় গতিবৃদ্ধি 1.99×

    95টি মাপা কুয়েরি কেস, Prisma-এর তুলনায় গড়৩০ সেপ, ২০২৬
  • Prisma v7 (7.10.0)Drizzle-এর তুলনায় 1.51×
    1.47×

    Prisma v7 (7.10.0): Prisma-এর তুলনায় গড় গতিবৃদ্ধি 1.47×

    95টি মাপা কুয়েরি কেস, Prisma-এর তুলনায় গড়৩০ সেপ, ২০২৬
  • Prisma v8 (8.1.0-dev.1)Drizzle-এর তুলনায় 1.63×
    1.54×

    Prisma v8 (8.1.0-dev.1): Prisma-এর তুলনায় গড় গতিবৃদ্ধি 1.54×

    95টি মাপা কুয়েরি কেস, Prisma-এর তুলনায় গড়৩০ সেপ, ২০২৬

SQLite

প্রতি রানে 84টি কুয়েরি কেস
  • Prisma v6 (6.19.3)Drizzle-এর তুলনায় 1.79×
    4.80×

    Prisma v6 (6.19.3): Prisma-এর তুলনায় গড় গতিবৃদ্ধি 4.80×

    84টি মাপা কুয়েরি কেস, Prisma-এর তুলনায় গড়৩০ সেপ, ২০২৬
  • Prisma v7 (7.10.0)Drizzle-এর তুলনায় 1.84×
    2.29×

    Prisma v7 (7.10.0): Prisma-এর তুলনায় গড় গতিবৃদ্ধি 2.29×

    84টি মাপা কুয়েরি কেস, Prisma-এর তুলনায় গড়৩০ সেপ, ২০২৬
  • Prisma v8 (8.1.0-dev.1)Drizzle-এর তুলনায় 1.63×
    2.10×

    Prisma v8 (8.1.0-dev.1): Prisma-এর তুলনায় গড় গতিবৃদ্ধি 2.10×

    84টি মাপা কুয়েরি কেস, Prisma-এর তুলনায় গড়৩০ সেপ, ২০২৬

সর্বশেষ benchmark-results/*-latest.json ফাইল থেকে বিল্ড টাইমে তৈরি। দুই ডেটাবেসের বারগুলো একই স্কেলে; অ্যাম্বার রং প্রতি ডেটাবেসের সেরা রান চিহ্নিত করে। আলাদা আলাদা কুয়েরি শেপে ফল ভিন্ন হয়।প্রতি কুয়েরির টেবিলসম্পূর্ণ বেঞ্চমার্ক ডেটা দেখুন

বিস্তারিত বেঞ্চমার্ক ফলাফল

Welch-এর t-test এবং 1ms ব্যবহারিক তাৎপর্য সীমাসহ পরিসংখ্যানগত তুলনা

এই ফলাফলগুলো রানটাইম মোড প্রতিফলিত করে, যেখানে প্রতিটি রিকোয়েস্টে কুয়েরি SQL-এ রূপান্তরিত হয়। প্রি-রেন্ডারড মোডে SQL বিল্ড টাইমে তৈরি হয় — রানটাইমে কোনো রূপান্তর ওভারহেড ছাড়াই raw প্যারামিটারাইজড কুয়েরি চলে।

PostgreSQLPrisma v6 (6.19.3)

Prisma-এর তুলনায় গড় 1.99xDrizzle-এর তুলনায় গড় 1.56x35/95টি তাৎপর্যপূর্ণ জয়60টি নয়েজ সীমার মধ্যে
৩০ সেপ, ২০২৬
টেস্টPrismaprisma-sqlDrizzleগতিবৃদ্ধিতাৎপর্যCV%n
findMany basic0.529ms±0.0640.231ms±0.2340.271ms~1.00x≈198.0%50
findMany where =0.501ms±0.00690.208ms±0.00940.347ms~1.00x≈15.6%50
findMany where >=16.51ms±0.2675.67ms±0.3387.43ms2.91x1.31x D***21.0%50
findMany where IN0.657ms±0.1420.292ms±0.0170.492ms~1.00x≈20.3%50
findMany where null0.280ms±0.0200.167ms±0.0120.177ms~1.00x≈25.7%50
findMany ILIKE0.297ms±0.00970.168ms±0.00890.278ms~1.00x≈18.6%50
findMany AND2.72ms±0.1611.11ms±0.1111.45ms2.45x1.31x D***31.5%50
findMany OR13.98ms±0.2864.69ms±0.2215.88ms2.98x1.25x D***17.0%50
findMany NOT0.639ms±0.0130.274ms±0.00910.478ms~1.00x≈12.2%50
findMany orderBy4.50ms±0.2191.48ms±0.0751.76ms3.03x1.18x D***18.5%50
findMany pagination0.342ms±0.0320.171ms±0.0260.295ms~1.00x≈43.2%50
findMany select0.294ms±0.00940.181ms±0.00720.176ms~1.00x≈14.0%50
findMany relation some1.69ms±0.0980.999ms±0.064—~1.00x≈22.1%50
findMany relation every2.17ms±0.0961.47ms±0.078—~1.00x≈18.9%50
findMany relation none26.02ms±0.51710.06ms±0.511—2.59x***18.0%50
findMany nested relation1.76ms±0.0761.24ms±0.060—~1.00x≈18.0%50
findMany complex2.94ms±0.1091.46ms±0.0681.73ms2.01x1.18x D***17.2%50
findFirst0.378ms±0.0320.175ms±0.0140.350ms~1.00x≈28.0%50
findFirst skip0.328ms±0.1070.147ms±0.00640.301ms~1.00x≈15.2%50
findUnique id0.232ms±0.00970.102ms±0.00550.207ms~1.00x≈18.6%50
findUnique email0.210ms±0.00720.090ms±0.00440.179ms~1.00x≈17.1%50
count0.109ms±0.00330.063ms±0.00300.064ms~1.00x≈16.2%50
count where0.469ms±0.0150.247ms±0.0160.287ms~1.00x≈22.2%50
aggregate count0.215ms±0.00780.155ms±0.0042—~1.00x≈9.2%50
aggregate sum/avg0.305ms±0.0140.261ms±0.0053—~1.00x≈7.1%50
aggregate where0.446ms±0.01000.239ms±0.0058—~1.00x≈8.7%50
aggregate min/max0.305ms±0.0150.268ms±0.010—~1.00x≈13.2%50
aggregate complete0.381ms±0.00610.292ms±0.0072—~1.00x≈8.8%50
groupBy0.419ms±0.0240.344ms±0.013—~1.00x≈12.8%50
groupBy count0.422ms±0.01000.358ms±0.0050—~1.00x≈4.8%50
groupBy multi0.544ms±0.0130.442ms±0.052—~1.00x≈38.9%50
groupBy having0.505ms±0.0110.375ms±0.0086—~1.00x≈8.2%50
groupBy + where0.550ms±0.0110.294ms±0.0064—~1.00x≈7.8%50
_count via include0.679ms±0.0130.511ms±0.013—~1.00x≈8.9%50
_count via include + relations1.55ms±0.0370.666ms±0.017—~1.00x≈9.3%50
groupBy aggregates0.557ms±0.00970.465ms±0.0091—~1.00x≈6.9%50
groupBy min/max0.531ms±0.00800.441ms±0.0053—~1.00x≈4.2%50
include list + nested to-one1.46ms±0.0290.337ms±0.032—4.32x***30.2%50
include list + nullable to-one2.59ms±0.0811.65ms±0.056—~1.00x≈11.9%50
include posts4.25ms±0.2162.35ms±0.1205.77ms1.81x2.45x D***18.9%50
include profile0.635ms±0.8710.540ms±0.2410.648ms~1.00x≈104.7%50
include 3 levels4.48ms±0.1484.03ms±0.1474.58ms~1.00x≈13.6%50
include 4 levels5.61ms±0.1823.39ms±0.1324.65ms1.65x1.37x D***13.9%50
include + where4.04ms±0.1762.88ms±0.3995.51ms~1.00x≈46.7%50
include + select nested2.52ms±0.1391.96ms±0.1854.42ms~1.00x≈31.8%50
findMany startsWith0.270ms±0.0280.140ms±0.0140.314ms~1.00x≈35.4%50
findMany endsWith0.563ms±0.0150.216ms±0.00690.369ms~1.00x≈11.1%50
findMany NOT contains0.627ms±0.0220.250ms±0.1040.447ms~1.00x≈121.8%50
findMany LIKE0.245ms±0.00940.111ms±0.00690.250ms~1.00x≈21.9%50
findMany <25.55ms±0.3987.55ms±0.29210.60ms3.39x1.40x D***13.4%50
findMany <=26.43ms±0.3717.78ms±0.22010.97ms3.40x1.41x D***10.2%50
findMany >15.55ms±0.5995.21ms±0.3566.78ms2.99x1.30x D***24.2%50
findMany NOT IN0.644ms±0.0130.282ms±0.0110.487ms~1.00x≈13.4%50
findMany isNot null0.642ms±0.0140.336ms±0.0170.362ms~1.00x≈18.6%50
orderBy multi-field4.99ms±0.1901.55ms±0.0761.88ms3.22x1.21x D***17.0%50
orderBy relation to-one4.10ms±0.1353.08ms±0.090—1.33x***10.2%50
orderBy relation + scalar5.02ms±0.2583.63ms±0.205—1.39x***20.0%50
orderBy nullable relation4.08ms±0.3002.94ms±0.181—1.39x***21.1%50
orderBy deep relation5.43ms±0.1864.04ms±0.174—1.34x***14.9%50
orderBy deep relation + scalar6.34ms±0.1354.62ms±0.100—1.37x***7.8%50
distinct status8.84ms±0.3761.56ms±0.181—5.66x***36.9%50
distinct multi12.04ms±0.1712.50ms±0.073—4.81x***10.3%50
cursor composite tuple1.61ms±0.0251.13ms±0.017—~1.00x≈5.3%50
cursor composite desc1.75ms±0.0371.31ms±0.021—~1.00x≈5.8%50
cursor prefix of orderBy2.70ms±0.1881.66ms±0.082—1.63x***18.1%50
select + include1.60ms±0.1010.309ms±0.0210.568ms5.16x1.84x D***24.6%50
_count relation1.74ms±0.3411.67ms±0.781—~1.00x≈123.8%50
_count multi-relation0.257ms±0.0290.218ms±0.045—~1.00x≈62.4%50
_count inside include2.32ms±0.1261.55ms±0.124—~1.00x≈32.0%50
_count inside nested select4.64ms±0.2023.69ms±0.266—~1.00x≈24.3%50
_count deep include5.49ms±0.2473.98ms±0.158—1.38x***14.1%50
ILIKE special chars0.425ms±0.0330.193ms±0.022—~1.00x≈36.5%50
LIKE case sensitive0.263ms±0.0100.110ms±0.0078—~1.00x≈24.0%50
findMany Date range0.424ms±0.0120.190ms±0.0120.321ms~1.00x≈21.1%50
count Date range1.14ms±0.0470.925ms±0.0520.995ms~1.00x≈19.8%50
findMany Date gte0.403ms±0.0250.178ms±0.00580.303ms~1.00x≈11.6%50
depth-1 low-fan0.566ms±0.0210.447ms±0.102—~1.00x≈73.7%50
depth-1 mid-fan4.21ms±0.1102.34ms±0.178—1.80x***26.3%50
depth-1 high-fan4.16ms±0.1222.25ms±0.130—1.85x***20.4%50
depth-1 wide3.11ms±0.1141.78ms±0.166—1.75x***31.3%50
depth-1 unbound39.65ms±3.789.43ms±0.884—4.21x***29.1%50
depth-24.78ms±0.1533.54ms±0.187—1.35x***18.6%50
depth-2 paginated Project→tasks3.16ms±0.1492.68ms±0.161—~1.00x≈20.6%50
depth-2 high-fan3.84ms±0.1852.86ms±0.229—~1.00x≈28.7%50
depth-2 wide4.90ms±0.1763.08ms±0.176—1.59x***20.6%50
depth-2 unbound65.60ms±1.5217.60ms±0.479—3.73x***4.4%10
depth-3 unbound15.32ms±0.2818.38ms±0.354—1.83x***15.8%50
depth-3 paginated2.44ms±0.1562.34ms±0.253—~1.00x≈32.7%50
depth-4 unbound9.96ms±0.2686.14ms±0.266—1.62x***15.7%50
depth-4 paginated3.42ms±0.1612.42ms±0.175—~1.00x≈23.6%50
findFirst depth-22.91ms±0.1142.30ms±0.173—~1.00x≈25.9%50
findUnique depth-2 Project→tasks→comment3.27ms±0.1132.16ms±0.173—1.52x***27.5%50
complex nested select4.51ms±0.4283.01ms±0.777—~1.00x≈65.7%50
ultra deep query15.94ms±0.5465.83ms±0.361—2.73x***22.0%50
transaction: (3 operations)3.00ms±0.2751.41ms±0.246—2.14x***53.2%50
*** p < 0.001** p < 0.01*  p < 0.05ns তাৎপর্যপূর্ণ নয়≈ 1ms নয়েজ সীমার মধ্যে± 95% আস্থা ব্যবধানCV% > 15% = উচ্চ ভ্যারিয়েন্স
রানটাইম মোড বেঞ্চমার্ক করা হয়েছে। প্রি-রেন্ডারড মোড রানটাইমে কুয়েরি-থেকে-SQL রূপান্তর সম্পূর্ণভাবে এড়িয়ে যায় — এখানে দেখানো সময়ের চেয়ে কম ল্যাটেন্সি আশা করুন, বিশেষ করে জটিল কুয়েরিতে, যেখানে রূপান্তরের খরচ আনুপাতিকভাবে বেশি।
GitHub-এ raw বেঞ্চমার্ক ডেটা দেখুন →

পদ্ধতি

  • –পুনরায় চালাতে: npm run bench (BENCHMARK_JSON_OUTPUT=1 JSON লেখে)। ফলাফল যায় benchmark-results/summary-.json-এ; v--latest.json থেকে এই পেজের ডেটা আসে।
  • –প্রতিটি কুয়েরি সব ক্লায়েন্টের জন্য একই ডেটাবেসে চলে: Prisma, prisma-sql, Drizzle। প্রতি টেস্টের স্যাম্পল সাইজ n কলামে দেখানো আছে।
  • –প্রতিটি পক্ষের জন্য দেখানো হয়: mean, median, stdDev, p95, p99, CV%। তাৎপর্য নির্ণয়ে 1ms ব্যবহারিক সীমাসহ Welch-এর t-test ব্যবহার করা হয়; এরর বার 95% CI।
  • –রানটাইম মোড মাপা হয়েছে: প্রতি রিকোয়েস্টে SQL রূপান্তর হয়। প্রি-রেন্ডারড (@optimize) কুয়েরি রূপান্তর সম্পূর্ণ এড়িয়ে যায় এবং এখানে দেখানোর চেয়ে দ্রুত চলে।
  • –প্রতিটি রানে হার্ডওয়্যার ও ভার্সন আলাদা হতে পারে - প্রতিটি JSON ফাইলে নিজস্ব টাইমস্ট্যাম্প থাকে। একই মেশিনের রান তুলনা করুন।

কী দ্রুত চলে, আর কী Prisma-তেই থাকে

PostgreSQL ও SQLite-এ আমাদের যাচাই করা প্রতিটি Prisma Client ফিচার। রাইট Prisma-তেই থাকে; শেপ সমর্থিত হলে রিড SQL-এ কম্পাইল হয়।

PostgreSQL
SQLite
মডেল মেথডকুয়েরি অপশনফিল্টারক্রম নির্ধারণঅ্যাগ্রিগেটক্লায়েন্ট APIফলাফলের টাইপ

যাচাই করা 73টি ফিচারের মধ্যে 25টি PostgreSQL-এ পুরোপুরি ত্বরান্বিত। 19টি Prisma-এর চেয়ে ভিন্ন ফলাফল দিতে পারে; পূর্ণ ম্যাপে প্রতিটির কারণসহ তালিকা আছে।

অবস্থা অনুযায়ী ফিচারের সংখ্যা
অবস্থাPostgreSQLSQLite
ত্বরান্বিত2521
আংশিক66
ফলব্যাক করে97
Prisma-তে চলে77
ভিন্ন হতে পারে1917
উপলব্ধ নয়24
শুধু prisma-sql52
Prisma-তে নেই06
যাচাই হয়নি03
পূর্ণ প্যারিটি ম্যাপ খুলুন
যাচাইকৃতআমরা সঠিকতা কীভাবে নিশ্চিত করি?সমর্থিত কুয়েরিগুলো PostgreSQL ও SQLite জুড়ে Prisma-এর সাথে মিলিয়ে যাচাই করা হয়, আর বেঞ্চমার্ক রিপোর্ট Prisma v6, v7, v8, Drizzle ও জেনারেট হওয়া SQL কভার করে।টেস্টিং পদ্ধতি দেখুন

এটি কীভাবে Prisma অপটিমাইজ করে

Prisma-এর API ও টাইপ রেখে Prisma-এর রিড এক্সিকিউশন পথ এড়িয়ে যান

  1. Prisma কুয়েরি ইন্টারসেপ্ট করা

    এক্সটেনশন রিড অপারেশন (findMany, findFirst, findUnique, count, aggregate, groupBy) এক্সিকিউট হওয়ার আগেই ধরে ফেলে

    generated/sql, অংশবিশেষ
    query: {
  $allModels: {
    async $allOperations({ model, operation, args, query }) {
      if (!ACCELERATED_METHODS.has(operation)) {
        return query(args)
      }
      return executeAccelerated(model, operation, args, query)
    },
  },
}

  2. অপটিমাইজড SQL জেনারেট করা

    Prisma কুয়েরিকে অপটিমাইজড JOIN সহ দ্রুত, প্যারামিটারাইজড SQL-এ রূপান্তর করে

    PostgreSQL-এর জন্য SQL
    SELECT user_t.id, user_t.email, user_t.status,
  COALESCE((
    SELECT COALESCE(json_agg(json_build_object(
      'id', posts_0.id,
      'title', posts_0.title,
      'authorId', posts_0."authorId"
    )), '[]'::json)
    FROM "public"."Post" posts_0
    WHERE posts_0."authorId" = user_t.id
  ), '[]'::json) AS posts
FROM "public"."User" user_t
WHERE user_t.status = $1

-- params ["ACTIVE"]

  3. সরাসরি এক্সিকিউট করা

    Prisma-এর রিড ওভারহেড এড়িয়ে postgres.js বা better-sqlite3 দিয়ে কুয়েরি চালায়

    generated/sql, অংশবিশেষ
    if (DIALECT === 'postgres') {
  await client.unsafe(sql, normalizedParams).forEach((row) => {
    results.push(row)
  })
  return results
}

const stmt = getOrPrepareStatement(client, sql)
return stmt.all(...normalizedParams)

  4. সামঞ্জস্যপূর্ণ ফলাফল ফেরত দেওয়া

    ফলাফল Prisma-এর প্রত্যাশিত আকারের সাথে মেলে। টাইপ, IntelliSense ও বিদ্যমান কুয়েরি কোড অপরিবর্তিত থাকে

    users.ts
    const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true },
})

users[0].email
users[0].posts[0].title

// Prisma Client-এর মতোই একই ইনফার করা টাইপ।
// Decimal, BigInt ও DateTime মান
// ভিন্ন হতে পারে; প্যারিটি ম্যাপে প্রতিটি কেস আছে।
যাচাইকৃত নিরাপদআমরা কীভাবে SQL ইনজেকশন প্রতিরোধ করি?প্যারামিটার বাইন্ডিং, স্কিমা-ভিত্তিক ফিল্ড চেক এবং বর্তমান নিরাপত্তা টেস্ট স্যুটসহ বহুস্তরের যাচাইনিরাপত্তার বিস্তারিত দেখুন

কেন এই Prisma এক্সটেনশন বেছে নেবেন?

Prisma-এর ডেভেলপার এক্সপেরিয়েন্স রেখে রিডে raw SQL এক্সিকিউশনের গতি পান

তাৎক্ষণিক Prisma গতিবৃদ্ধি
একবারের সেটআপেই Prisma রিড দ্রুত হয়। কোনো রিফ্যাক্টরিং নয়, মাইগ্রেশন নয়, ডাউনটাইম নয়।
আপনার Prisma টাইপ রেখে দিন
পূর্ণ TypeScript সমর্থন বজায় থাকে। রিড দ্রুত করার সময়ও টাইপ ইনফারেন্স, অটোকমপ্লিট ও কম্পাইল-টাইম সেফটি অক্ষুণ্ণ থাকে।
প্রোডাকশনে পরীক্ষিত সমাধান
বর্তমান প্যারিটি টেস্ট সাম্প্রতিক Prisma ভার্সনগুলোতে সমর্থিত রিড যাচাই করে। আপনার Prisma ভার্সন ও ওয়ার্কলোডের সাথে সামঞ্জস্য যাচাই করার পর প্রোডাকশন অ্যাপে এটি ব্যবহার করুন।
একাধিক ডেটাবেস সমর্থন
PostgreSQL (Neon, Supabase সহ) ও SQLite-এ Prisma রিড অপটিমাইজ করুন।
প্রি-কম্পাইলড বিকল্প
ঐচ্ছিক জেনারেটর বিল্ড টাইমে SQL তৈরি করে, ফলে আপনার সবচেয়ে ঘন ঘন চলা কুয়েরির ওভারহেড মাইক্রোসেকেন্ডে নেমে আসে।
সার্ভারলেসের জন্য প্রস্তুত (Node রানটাইম)
সার্ভারলেস Node রানটাইমে কাজ করে। Edge রানটাইমে সমর্থন রানটাইমের সীমাবদ্ধতা ও আপনার ব্যবহৃত ড্রাইভারের ওপর নির্ভর করে।

দ্রুত রিডের বাইরেও

prisma-sql এমন সক্ষমতা যোগ করে যা Prisma Client-এ নেই। একই টাইপ, একই কোড স্টাইল।

$batch

N-টি ড্যাশবোর্ড কুয়েরি, একটি রাউন্ড ট্রিপ

স্বাধীন রিডগুলোকে একটি PostgreSQL রাউন্ড ট্রিপে একত্র করুন। টাইপসহ অবজেক্ট ফলাফল, Promise.all নিয়ে ঝামেলা নেই।

const dash = await prisma.$batch((b) => ({
  users: b.user.count(),
  posts: b.post.findMany({ take: 10 }),
  stats: b.task.aggregate({ _count: true }),
}))

@optimize

সবচেয়ে ঘন ঘন চলা কুয়েরি আগেই তৈরি করে রাখুন

schema.prisma-তে একটি মডেলে অ্যানোটেশন দিন। generate-এর সময় হুবহু SQL তৈরি হয়ে যায়; রানটাইমে মিলে যাওয়া শেপগুলো রূপান্তর পুরোপুরি এড়িয়ে যায়।

/// @optimize {
///   "method": "findMany",
///   "query": {
///     "where": { "status": "$status" },
///     "take": "$take"
///   }
/// }
model User { ... }

কার্ডিনালিটি প্ল্যানার

কৌশল ঠিক হয় ডেটা দেখে, অনুমানে নয়

সংগৃহীত রিলেশন পরিসংখ্যান অনুযায়ী ফ্ল্যাট JOIN, কোরিলেটেড সাবকুয়েরি এবং where-in সেগমেন্টেড লোডিংয়ের মধ্যে কৌশল বদলানো হয়। বড় চাইল্ড টেবিলে কখনো প্রতি-প্যারেন্ট স্ক্যান হয় না।

prisma-sql-collect-stats \
  --output dist/planner.generated.js \
  --prisma-client dist/client/index.js

যখন Prisma-এর পারফরম্যান্স সবচেয়ে গুরুত্বপূর্ণ

সাধারণ পরিস্থিতি, যেখানে এই এক্সটেনশন বাস্তব পার্থক্য আনে

অ্যানালিটিক্স ও রিপোর্টিং

Prisma-এর অ্যাগ্রিগেশন ও groupBy অপারেশন সরাসরি SQL এক্সিকিউশন থেকে উল্লেখযোগ্য সুবিধা পায়

  • 5× দ্রুত groupBy রিপোর্ট দ্রুত করে
  • দ্রুততর aggregate কুয়েরি
  • কম ল্যাটেন্সিতে রিয়েল-টাইম মেট্রিক্স

উচ্চ-ট্রাফিক API

লোডের মধ্যে প্রতি কুয়েরির ওভারহেড জমতে থাকে, বিশেষ করে রিড-প্রধান এন্ডপয়েন্টে

  • কম API রেসপন্স টাইম
  • প্রতি ইনস্ট্যান্সে আরও বেশি রিকোয়েস্ট সামলানো
  • ইনফ্রাস্ট্রাকচারের খরচ কমানো

সার্ভারলেস ফাংশন

সার্ভারলেসে প্রতিটি মিলিসেকেন্ড গুরুত্বপূর্ণ: যেখানে দরকার সেখানে রিড ল্যাটেন্সি কমান

  • রিডে ভালো p95/p99
  • দ্রুত রিডের ফলে কম খরচ
  • রিফ্যাক্টর ছাড়াই দ্রুত রিড

মোবাইল ব্যাকএন্ড

ব্যবহারকারীরা ল্যাটেন্সি টের পান: দ্রুত রিড সঙ্গে সঙ্গে অনুভূত UX উন্নত করে

  • দ্রুত ফিড লোডিং
  • দ্রুত পেজিনেশন
  • আরও রেসপনসিভ ইন্টারঅ্যাকশন

3 ধাপে Prisma অপটিমাইজ করুন

60 সেকেন্ডেরও কম সময়ে Prisma রিড দ্রুত করুন

  1. Prisma এক্সটেনশন ইনস্টল করুন

    Terminal
    # PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

  2. Prisma Client-এ এক্সটেনশন যোগ করুন

    schema.prisma
    generator client {
  provider = "prisma-client"
}

generator sql {
  provider = "prisma-sql-generator"
}
    Terminal
    npx prisma generate
    db.ts
    import { PrismaClient } from '@prisma/client'
import { speedExtension, type SpeedClient } from './generated/sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!)
const basePrisma = new PrismaClient()

export const prisma = basePrisma.$extends(
  speedExtension({ postgres: sql }),
) as SpeedClient<typeof basePrisma>

  3. স্বাভাবিকভাবে Prisma ব্যবহার করুন

    users.ts
    const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true },
})

SQLite: একটি better-sqlite3 ডেটাবেসসহ speedExtension({ sqlite: db }) পাস করুন।পূর্ণ সেটআপ গাইড

Prisma পারফরম্যান্স FAQ

Prisma রিড অপটিমাইজ করা নিয়ে সাধারণ প্রশ্ন

Prisma-তে ওভারহেড কেন থাকে?

Prisma স্কিমা-ভিত্তিক যাচাই, সামঞ্জস্যপূর্ণ কুয়েরি আচরণ ও ফলাফল গঠনের মতো API নিশ্চয়তা বাস্তবায়ন করে বলে ওভারহেড যোগ হয়। এই স্তরগুলো চমৎকার ডেভেলপার এক্সপেরিয়েন্স দেয়, কিন্তু সরাসরি raw SQL চালানোর তুলনায় বেশি সময় নেয়।

Prisma কুয়েরি কীভাবে অপটিমাইজ করব?

এই এক্সটেনশন যোগ করে রিড-প্রধান Prisma ওয়ার্কলোড অপটিমাইজ করুন। এটি Prisma-এর API ও টাইপ রেখে postgres.js বা better-sqlite3 দিয়ে সরাসরি SQL-এ রিড অপারেশন চালায়। সেটআপ মানে ইনিশিয়ালাইজেশনে ছোট একটি পরিবর্তন; বিদ্যমান কুয়েরি রিফ্যাক্টর করতে হয় না।

Prisma কি raw SQL-এর চেয়ে ধীর?

অনেক রিড ওয়ার্কলোডে, হ্যাঁ। raw SQL এক্সিকিউশনের তুলনায় আর্কিটেকচারগত ওভারহেড থাকে। এই এক্সটেনশনের লক্ষ্য হলো Prisma-এর DX বজায় রেখে সরাসরি SQL চালিয়ে রিড ল্যাটেন্সি কমানো।

বিদ্যমান কুয়েরি না বদলে কি Prisma দ্রুত করা যায়?

হ্যাঁ। Prisma Client ইনিশিয়ালাইজ করার সময় একবার এক্সটেনশন যোগ করুন, আর বিদ্যমান Prisma কুয়েরি কোড যেমন আছে তেমন রাখুন। রিড অপারেশন দ্রুত চলে, আর আপনার Prisma API, টাইপ ও স্কিমা একই থাকে।

এটা কি প্রোডাকশনে কাজ করে?

হ্যাঁ, সমর্থিত রিড পথে প্রোডাকশন ব্যবহারের জন্যই এটি ডিজাইন করা। রোলআউটের আগে সবসময় আপনার Prisma ভার্সনের সাথে সামঞ্জস্য যাচাই করুন এবং নিজের রিগ্রেশন টেস্ট চালান।

Prisma অ্যাগ্রিগেশন ধীর হয় কেন?

অ্যাগ্রিগেশন ও groupBy প্রায়ই নির্দিষ্ট ওভারহেড (কুয়েরি প্রসেসিং ও ফলাফল গঠন) বাড়িয়ে তোলে এবং এতে বড় মধ্যবর্তী রেজাল্ট সেট জড়িত থাকতে পারে। এই এক্সটেনশন সরাসরি SQL জেনারেট করে এই রিডগুলো অপটিমাইজ করে, যা সাধারণত অ্যাগ্রিগেশন-প্রধান এন্ডপয়েন্টে ল্যাটেন্সি কমায়।

Prisma দ্রুত করতে প্রস্তুত?

সমর্থিত PostgreSQL ও SQLite রিডের জন্য বর্তমান বেঞ্চমার্ক টেবিল দেখুন

Prisma-SQL ইনস্টল করুনGitHub-এ দেখুন