🚀 سست Prisma کا حل

سست Prisma کویریز ٹھیک کریں
اپنی API کو 2–7× تیز کریں (زیادہ سے زیادہ 53.5×)

کیا Prisma سست ہے؟ آپ اکیلے نہیں۔ Prisma کا DX پسند ہے مگر بہتر performance چاہیے؟ سست Prisma کویریز کو 2–7× تیز کریں (SQLite relation filters پر زیادہ سے زیادہ 53.5×) بغیر کسی موجودہ query کو بدلے۔

ابھی Prisma تیز کریں دیکھیں کیسے کام کرتا ہے
تیز Prisma reads
کوئی query تبدیلی نہیں
Production-ready
137 E2E tests
ایک لائن میں سست Prisma ٹھیک کریں 
import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})
2–7×
تیز Prisma reads
عام speedup
0
Query تبدیلیاں
اپنے موجودہ Prisma calls رکھیں
137
E2E tests
Verified solution
100%
Type safety
وہی Prisma API

Prisma کیوں سست ہے؟

Prisma کی evolution اور performance characteristics سمجھنے سے واضح ہوتا ہے کہ یہ extension کیوں موجود ہے۔

Prisma کا سفر: پہلے DX، اور scale پر performance اہم

🎯 2019: جدید Prisma کی پیدائش

Prisma 2 2019 میں لانچ ہوا، اور type-safe database access اور schema سے generated types کے ذریعے TypeScript ORM landscape بدل دیا۔ Prisma نے engine-based architecture متعارف کرایا تاکہ queries translate ہوں، validate ہوں، اور مضبوط guarantees ملیں جو traditional JavaScript ORMs کے ساتھ حاصل کرنا مشکل تھا۔

⚡ 2020–2022: تیز ترقی اور فیچرز میں اضافہ

Prisma نے nested writes، transactions، اور middleware جیسے طاقتور فیچرز شامل کیے۔ فیچرز بڑھے، لیکن ہر query پھر بھی architectural cost ادا کرتی ہے: queries کو represent، validate، execute کیا جاتا ہے اور نتائج Prisma API کے مطابق shape کیے جاتے ہیں۔

📊 2023: scale پر overhead نمایاں ہوتا ہے

جیسے جیسے زیادہ ٹیمیں high-traffic workloads میں Prisma deploy کرتی ہیں، per-query fixed overhead قابلِ پیمائش ہو جاتا ہے۔ یہ read-heavy endpoints، analytics، aggregations، اور بڑے result sets میں سب سے زیادہ نظر آتا ہے۔ یہ bug نہیں؛ Prisma کی guarantees اور API behavior کی cost ہے۔

🚀 2024–2025: Prisma کی performance پر کام جاری

Prisma نے performance اور engine changes پر فوکس کرتے ہوئے بڑے updates جاری کیے۔ بہتری کے باوجود raw SQL کو براہِ راست execute کرنے کے مقابلے میں parsing، validating، planning اور result shaping کی ایک unavoidable cost رہتی ہے۔

🎯 2026: prisma-sql Extension جاری

یہ extension read performance پر فوکس کرتی ہے۔ findMany، findFirst، findUnique، count، aggregate، اور groupBy کے لیے Prisma کے read execution path کو bypass کرتی ہے، جبکہ writes، migrations، schema management اور type generation کے لیے Prisma برقرار رہتا ہے۔ rollout سے پہلے اپنی Prisma version کے ساتھ compatibility validate کریں۔

💡 یہ extension کیوں موجود ہے

Prisma نے اپنے اہداف کے لیے درست architectural choices کیے: type safety، developer experience اور cross-database behavior۔ مگر یہی choices scale پر noticeable overhead بناتے ہیں۔ یہ extension Prisma کو replace نہیں کرتی — یہ reads کو optimize کرتی ہے ان ٹیموں کے لیے جو Prisma کا DX بھی چاہتی ہیں اور جہاں ضرورت ہو وہاں تیز execution بھی۔

Query translation layer

Prisma آپ کے query inputs کو database-specific SQL میں translate کرتا ہے۔ یہ cross-database behavior اور Prisma API semantics دیتا ہے، مگر database کے SQL دیکھنے سے پہلے processing time بڑھاتا ہے۔

Validation اور type guarantees

Prisma schema کے خلاف queries validate کرتا ہے اور API-level guarantees enforce کرتا ہے۔ یہ safeguards bugs کی کچھ اقسام روکتے ہیں، مگر ہر query پر overhead بھی بڑھاتے ہیں۔

Result shaping

Results کو Prisma API behavior کے مطابق shape کیا جاتا ہے۔ DX اور consistency کے لیے اچھا ہے، مگر latency بڑھاتا ہے، خاص طور پر بڑے result sets اور complex includes میں۔

یہ extension Prisma کو complement کرتی ہے اور read queries کے لیے ایک تیز راستہ دیتی ہے۔ آپ Prisma کی پسندیدہ چیزیں برقرار رکھتے ہیں اور typical cases میں 2–7× تیز reads (اور SQLite relation filters میں زیادہ سے زیادہ 53.5×) حاصل کرتے ہیں جب performance اہم ہو۔

کتنا تیز؟ حقیقی بینچ مارکس

Prisma v6، v7، Drizzle ORM اور Prisma-SQL کے درمیان جامع موازنہ

بینچ مارک ماحول: MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • ہر ڈیٹابیس کے لیے 137 ٹیسٹ کیسز

PostgreSQL

57 ٹیسٹ کیسز کا اوسط

Prisma v6
2.10ms
Prisma v7
1.95ms
1.08× faster
Drizzle ORM
1.40ms
1.50× faster
Prisma-SQL ⚡
0.90ms
2.34× faster
6.3×
DISTINCT کوئریز
Prisma v6 کے مقابلے میں
5.5×
ریلیشن فلٹرز
Prisma v6 کے مقابلے میں ("none"-فلٹر)

SQLite

56 ٹیسٹ کیسز کا اوسط

Prisma v6
5.48ms
Prisma v7
4.12ms
1.33× faster
Drizzle ORM
2.11ms
2.60× faster
Prisma-SQL ⚡
0.73ms
7.50× faster
12.6×
سادہ کوئریز
Prisma v6 کے مقابلے میں
69.7×
ریلیشن فلٹرز
Prisma v6 کے مقابلے میں ("none"-فلٹر)

بینچ مارکس ہر ڈیٹابیس کے لیے 137 E2E ٹیسٹس پر مبنی ہیں۔ Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. مکمل بینچ مارک ڈیٹا دیکھیں →

تفصیلی بینچ مارک نتائج

Welch کے t-test اور 1ms عملی اہمیت کی حد کے ساتھ شماریاتی موازنہ

یہ نتائج رن ٹائم موڈ کی عکاسی کرتے ہیں، جہاں ہر درخواست پر کوئریز کو SQL میں تبدیل کیا جاتا ہے۔ پری رینڈرڈ موڈ میں، SQL بلڈ کے وقت تیار کیا جاتا ہے — رن ٹائم بغیر کسی تبدیلی کے اضافی بوجھ کے خام پیرامیٹرائزڈ کوئریز کو چلایا جاتا ہے۔

PostgreSQL Prisma v6

اوسط 2.07x بمقابلہ Prisma اوسط 1.68x بمقابلہ Drizzle 28/95 شماریاتی طور پر اہم کامیابیاں 65 شور کی حد کے اندر
Mar 7, 2026
ٹیسٹ Prisma prisma-sql Drizzle رفتار میں اضافہ اہمیت CV% n
findMany basic 0.536ms ±0.016 0.272ms ±0.043 1.37ms ~1.00x ≈ 57.0% 50
findMany where = 0.596ms ±0.046 0.354ms ±0.022 0.442ms ~1.00x ≈ 22.3% 50
findMany where >= 16.48ms ±0.251 4.89ms ±0.382 6.48ms 3.37x 1.33x D *** 28.2% 50
findMany where IN 0.609ms ±0.034 0.325ms ±0.016 0.436ms ~1.00x ≈ 17.5% 50
findMany where null 0.254ms ±0.0094 0.122ms ±0.0030 0.167ms ~1.00x ≈ 8.7% 50
findMany ILIKE 0.290ms ±0.043 0.231ms ±0.0083 0.296ms ~1.00x ≈ 13.2% 50
findMany AND 2.77ms ±0.076 1.00ms ±0.109 2.12ms 2.77x 2.12x D *** 39.3% 50
findMany OR 14.10ms ±0.361 4.05ms ±0.388 6.96ms 3.48x 1.72x D *** 34.6% 50
findMany NOT 0.631ms ±0.042 0.363ms ±0.026 0.454ms ~1.00x ≈ 26.3% 50
findMany orderBy 2.11ms ±0.080 0.893ms ±0.081 1.12ms 2.36x 1.25x D *** 32.7% 50
findMany pagination 0.248ms ±0.013 0.217ms ±0.0089 0.228ms ~1.00x ≈ 14.9% 50
findMany select 0.309ms ±0.058 0.101ms ±0.0064 0.116ms ~1.00x ≈ 22.6% 50
findMany relation some 0.910ms ±0.030 0.450ms ±0.016 — ~1.00x ≈ 12.6% 50
findMany relation every 0.710ms ±0.026 0.491ms ±0.012 — ~1.00x ≈ 8.7% 50
findMany relation none 31.70ms ±4.16 7.65ms ±0.483 — 4.15x *** 22.8% 50
findMany nested relation 0.952ms ±0.088 1.06ms ±0.138 — ~1.00x ≈ 46.7% 50
findMany complex 1.12ms ±0.029 0.520ms ±0.017 0.651ms ~1.00x ≈ 11.7% 50
findFirst 0.240ms ±0.013 0.195ms ±0.014 0.262ms ~1.00x ≈ 25.0% 50
findFirst skip 0.284ms ±0.018 0.176ms ±0.0080 0.219ms ~1.00x ≈ 16.7% 50
findUnique id 0.220ms ±0.016 0.163ms ±0.028 0.167ms ~1.00x ≈ 61.9% 50
findUnique email 0.180ms ±0.012 0.104ms ±0.0075 0.133ms ~1.00x ≈ 26.0% 50
count 0.124ms ±0.026 0.048ms ±0.0019 0.063ms ~1.00x ≈ 13.8% 50
count where 0.435ms ±0.0094 0.265ms ±0.011 0.273ms ~1.00x ≈ 15.4% 50
aggregate count 0.230ms ±0.0069 0.151ms ±0.0028 — ~1.00x ≈ 6.5% 50
aggregate sum/avg 0.355ms ±0.018 0.263ms ±0.013 — ~1.00x ≈ 18.0% 50
aggregate where 0.438ms ±0.010 0.275ms ±0.014 — ~1.00x ≈ 18.9% 50
aggregate min/max 0.344ms ±0.015 0.289ms ±0.031 — ~1.00x ≈ 38.6% 50
aggregate complete 0.420ms ±0.014 0.317ms ±0.033 — ~1.00x ≈ 37.4% 50
groupBy 0.447ms ±0.015 0.339ms ±0.011 — ~1.00x ≈ 11.4% 50
groupBy count 0.461ms ±0.011 0.381ms ±0.014 — ~1.00x ≈ 13.0% 50
groupBy multi 0.573ms ±0.019 0.431ms ±0.0097 — ~1.00x ≈ 8.1% 50
groupBy having 0.585ms ±0.034 0.473ms ±0.011 — ~1.00x ≈ 8.6% 50
groupBy + where 0.596ms ±0.031 0.431ms ±0.038 — ~1.00x ≈ 31.5% 50
_count via include 0.702ms ±0.023 0.704ms ±0.040 — ~1.00x ≈ 20.4% 50
_count via include + relations 1.86ms ±0.108 1.48ms ±0.072 — ~1.00x ≈ 17.7% 50
groupBy aggregates 0.576ms ±0.027 0.578ms ±0.062 — ~1.00x ≈ 38.8% 50
groupBy min/max 0.571ms ±0.048 0.589ms ±0.073 — ~1.00x ≈ 44.8% 50
include list + nested to-one 1.77ms ±0.103 0.460ms ±0.034 — 3.86x *** 26.9% 50
include list + nullable to-one 2.77ms ±0.100 2.14ms ±0.170 — ~1.00x ≈ 28.6% 50
include posts 2.86ms ±0.201 1.07ms ±0.069 6.00ms 2.66x 5.58x D *** 23.2% 50
include profile 0.533ms ±0.027 0.489ms ±0.030 0.549ms ~1.00x ≈ 21.8% 50
include 3 levels 1.99ms ±0.100 1.70ms ±0.190 1.96ms ~1.00x ≈ 40.2% 50
include 4 levels 2.45ms ±0.103 1.25ms ±0.030 3.81ms 1.96x 3.05x D *** 8.8% 50
include + where 2.61ms ±0.100 0.948ms ±0.100 4.59ms 2.76x 4.84x D *** 38.1% 50
include + select nested 2.27ms ±0.124 1.34ms ±0.106 3.71ms ~1.00x ≈ 28.5% 50
findMany startsWith 0.282ms ±0.031 0.185ms ±0.030 0.230ms ~1.00x ≈ 58.7% 50
findMany endsWith 0.640ms ±0.057 0.296ms ±0.049 0.470ms ~1.00x ≈ 59.0% 50
findMany NOT contains 0.661ms ±0.024 0.329ms ±0.050 0.413ms ~1.00x ≈ 55.1% 50
findMany LIKE 0.257ms ±0.026 0.181ms ±0.0061 0.208ms ~1.00x ≈ 12.3% 50
findMany < 27.72ms ±2.31 6.64ms ±0.325 11.44ms 4.18x 1.72x D *** 17.7% 50
findMany <= 28.41ms ±0.842 6.96ms ±0.419 11.50ms 4.08x 1.65x D *** 21.7% 50
findMany > 18.50ms ±3.09 4.00ms ±0.196 6.24ms 4.63x 1.56x D *** 17.7% 50
findMany NOT IN 0.593ms ±0.032 0.285ms ±0.012 0.351ms ~1.00x ≈ 15.4% 50
findMany isNot null 0.580ms ±0.017 0.194ms ±0.0036 0.294ms ~1.00x ≈ 6.6% 50
orderBy multi-field 5.19ms ±0.480 3.14ms ±1.04 1.51ms 1.66x 0.48x D ** 119.3% 50
orderBy relation to-one 2.38ms ±0.066 1.72ms ±0.131 — ~1.00x ≈ 27.5% 50
orderBy relation + scalar 2.22ms ±0.039 1.69ms ±0.093 — ~1.00x ≈ 19.9% 50
orderBy nullable relation 1.94ms ±0.056 1.30ms ±0.058 — ~1.00x ≈ 16.0% 50
orderBy deep relation 2.45ms ±0.070 1.73ms ±0.040 — ~1.00x ≈ 8.3% 50
orderBy deep relation + scalar 3.38ms ±0.250 2.07ms ±0.053 — 1.63x *** 9.2% 50
distinct status 11.52ms ±2.73 1.38ms ±0.137 — 8.33x *** 35.8% 50
distinct multi 14.12ms ±0.732 2.60ms ±0.054 — 5.43x *** 7.5% 50
cursor composite tuple 1.97ms ±0.081 1.50ms ±0.081 — ~1.00x ≈ 19.4% 50
cursor composite desc 2.91ms ±1.29 1.66ms ±0.135 — 1.75x ns 29.4% 50
cursor prefix of orderBy 2.03ms ±0.074 1.38ms ±0.040 — ~1.00x ≈ 10.4% 50
select + include 1.19ms ±0.081 0.254ms ±0.015 0.415ms ~1.00x ≈ 21.8% 50
_count relation 0.898ms ±0.070 0.648ms ±0.034 — ~1.00x ≈ 19.2% 50
_count multi-relation 0.244ms ±0.014 0.172ms ±0.0080 — ~1.00x ≈ 17.1% 50
_count inside include 1.37ms ±0.055 1.35ms ±0.130 — ~1.00x ≈ 34.7% 50
_count inside nested select 1.91ms ±0.049 1.43ms ±0.057 — ~1.00x ≈ 14.4% 50
_count deep include 1.92ms ±0.040 1.40ms ±0.044 — ~1.00x ≈ 11.4% 50
ILIKE special chars 0.511ms ±0.262 0.177ms ±0.0064 — ~1.00x ≈ 12.8% 50
LIKE case sensitive 0.213ms ±0.012 0.164ms ±0.0053 — ~1.00x ≈ 11.5% 50
findMany Date range 0.368ms ±0.018 0.517ms ±0.019 0.833ms ~1.00x ≈ 13.6% 50
count Date range 0.508ms ±0.016 0.817ms ±0.295 0.438ms ~1.00x ≈ 130.1% 50
findMany Date gte 0.387ms ±0.032 0.184ms ±0.0025 0.242ms ~1.00x ≈ 5.0% 50
depth-1 low-fan 0.502ms ±0.045 0.666ms ±0.303 — ~1.00x ≈ 164.1% 50
depth-1 mid-fan 3.02ms ±0.187 1.26ms ±0.148 — 2.40x *** 42.3% 50
depth-1 high-fan 3.49ms ±0.138 1.01ms ±0.066 — 3.44x *** 23.3% 50
depth-1 wide 6.05ms ±1.65 1.51ms ±0.104 — 4.00x *** 24.8% 50
depth-1 unbound 43.36ms ±2.79 8.43ms ±0.343 — 5.14x *** 14.7% 50
depth-2 3.79ms ±0.176 2.60ms ±0.150 — 1.45x *** 20.8% 50
depth-2 paginated Project→tasks 1.52ms ±0.067 1.66ms ±0.174 — ~1.00x ≈ 37.9% 50
depth-2 high-fan 2.14ms ±0.044 1.21ms ±0.060 — ~1.00x ≈ 18.1% 50
depth-2 wide 5.24ms ±0.307 1.92ms ±0.179 — 2.73x *** 33.8% 50
depth-2 unbound 78.61ms ±23.12 13.71ms ±0.633 — 5.74x *** 7.5% 10
depth-3 unbound 16.38ms ±1.37 6.59ms ±0.241 — 2.49x *** 13.2% 50
depth-3 paginated 2.04ms ±0.117 2.19ms ±0.542 — ~1.00x ≈ 89.3% 50
depth-4 unbound 9.62ms ±0.235 3.27ms ±0.186 — 2.94x *** 20.5% 50
depth-4 paginated 2.56ms ±0.095 1.78ms ±0.230 — ~1.00x ≈ 46.4% 50
findFirst depth-2 3.53ms ±0.968 1.52ms ±0.134 — 2.33x *** 32.0% 50
findUnique depth-2 Project→tasks→comment 2.77ms ±0.164 2.94ms ±0.761 — ~1.00x ≈ 93.5% 50
complex nested select 5.70ms ±0.317 4.49ms ±0.196 — 1.27x *** 15.7% 50
ultra deep query 7.62ms ±0.180 11.97ms ±5.92 — 0.64x ns 178.5% 50
transaction: (3 operations) 2.91ms ±0.054 1.23ms ±0.069 — 2.37x *** 20.4% 50
*** p < 0.001 ** p < 0.01 *  p < 0.05 ns شماریاتی طور پر اہم نہیں ≈ 1ms شور کی حد کے اندر ± 95% اعتماد کا وقفہ CV% > 15% = زیادہ تغیر
رن ٹائم موڈ کا بینچ مارک کیا گیا۔ پری رینڈرڈ موڈ رن ٹائم پر کوئری سے SQL میں تبدیلی کو مکمل طور پر نظر انداز کرتا ہے — یہاں دکھائی گئی تاخیر سے کم تاخیر کی توقع کریں، خاص طور پر پیچیدہ کوئریز میں جہاں تبدیلی کی لاگت نسبتاً زیادہ ہوتی ہے۔
GitHub پر خام بینچ مارک ڈیٹا دیکھیں →
✓ Validated

ہم correctness کیسے یقینی بناتے ہیں؟

ہر query کو PostgreSQL اور SQLite میں 137 end-to-end tests کے ذریعے Prisma کے خلاف validate کیا جاتا ہے

Testing Methodology دیکھیں →

یہ Prisma کو کیسے optimize کرتی ہے

Prisma کی API اور types برقرار رکھتے ہوئے Prisma read execution path کو bypass کریں

1

Prisma queries intercept کریں

Extension read operations (findMany, findFirst, findUnique, count, aggregate, groupBy) کو execute ہونے سے پہلے پکڑتی ہے

2

Optimized SQL generate کریں

Prisma queries کو تیز، parameterized SQL میں convert کریں optimized JOINs کے ساتھ

3

Direct execute کریں

postgres.js یا better-sqlite3 کے ذریعے queries چلائیں، Prisma read overhead bypass کرتے ہوئے

4

Compatible results واپس کریں

Results Prisma کی expected shape سے match کرتے ہیں۔ Types، IntelliSense اور موجودہ query code تبدیل نہیں ہوتا

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

// Direct SQL execution for reads
// Benchmarked around ~1.00ms on this workload
// Same Prisma query code
🔒 Verified Secure

How do we prevent SQL injection?

Multi-layer validation with parameter binding, schema-based field checks, and 137 security tests (current suite)

View Security Details →

یہ Prisma extension کیوں منتخب کریں؟

Reads کے لیے raw SQL execution کی رفتار حاصل کریں اور Prisma کا developer experience برقرار رکھیں

فوری Prisma speedup

One-time setup Prisma reads کو accelerate کرتا ہے۔ نہ refactoring، نہ migration، نہ downtime۔

اپنے Prisma types برقرار رکھیں

Full TypeScript support برقرار۔ Type inference، autocomplete اور compile-time safety محفوظ رہتے ہیں جبکہ reads تیز ہوتی ہیں۔

Production-tested solution

137 E2E tests حالیہ Prisma versions کے ساتھ compatibility validate کرتے ہیں۔ Production apps میں Prisma reads تیز کرنے کے لیے استعمال ہوتی ہے۔

Multiple database support

PostgreSQL (Neon، Supabase سمیت) اور SQLite پر Prisma reads optimize کریں۔

Pre-compiled option

Optional generator build-time SQL بناتا ہے، آپ کی hottest queries کے لیے overhead کو microseconds تک کم کرتا ہے۔

Serverless ready (Node runtimes)

Serverless Node runtimes میں کام کرتا ہے۔ Edge runtime support runtime constraints اور استعمال ہونے والے driver پر منحصر ہے۔

جہاں Prisma performance سب سے زیادہ اہم ہے

عام scenarios جہاں یہ extension واقعی فرق ڈالتی ہے

📊 Analytics اور Reporting

Prisma aggregations اور groupBy operations direct SQL execution سے خاصا فائدہ اٹھاتے ہیں

  • 5× تیز groupBy رپورٹس کو تیز کرتا ہے
  • Faster aggregate queries
  • کم latency کے ساتھ real-time metrics

🚀 High-traffic APIs

Load میں per-query overhead جمع ہوتا ہے، خاص طور پر read-heavy endpoints میں

  • کم API response times
  • ہر instance پر زیادہ requests handle کریں
  • Infrastructure costs کم کریں

☁️ Serverless functions

Serverless میں ہر millisecond اہم ہے: جہاں ضروری ہو وہاں read latency کم کریں

  • Reads پر بہتر p95/p99
  • تیز reads سے کم costs
  • Refactors کے بغیر تیز reads

📱 Mobile backends

Users latency محسوس کرتے ہیں: تیز reads فوری طور پر perceived UX بہتر کرتی ہیں

  • تیز feed loading
  • تیز pagination
  • زیادہ responsive interactions

3 مراحل میں Prisma optimize کریں

60 seconds سے کم میں Prisma reads accelerate کریں

① Prisma extension انسٹال کریں 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② Prisma Client میں extension شامل کریں 

import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

③ Prisma کو معمول کے مطابق استعمال کریں 

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

Prisma Performance FAQ

Prisma reads optimize کرنے کے عام سوالات

Prisma میں overhead کیوں ہوتا ہے؟

Prisma overhead اس لیے بڑھاتا ہے کہ یہ schema-based validation، consistent query behavior اور result shaping جیسے API guarantees نافذ کرتا ہے۔ یہ layers developer experience بہتر بناتی ہیں مگر raw SQL براہِ راست execute کرنے کے مقابلے میں وقت لیتی ہیں۔

میں Prisma queries کو کیسے optimize کروں؟

Read-heavy Prisma workloads کو اس extension کے ذریعے optimize کریں۔ یہ reads کو postgres.js یا better-sqlite3 کے ذریعے direct SQL سے execute کرتی ہے جبکہ Prisma کی API اور types برقرار رہتے ہیں۔ Setup ایک چھوٹی initialization تبدیلی ہے اور موجودہ queries refactor کرنے کی ضرورت نہیں۔

کیا Prisma raw SQL سے سست ہے؟

کئی read workloads میں، ہاں۔ raw SQL execution کے مقابلے میں architectural overhead ہوتا ہے۔ یہ extension Prisma کا DX برقرار رکھتے ہوئے SQL direct execute کر کے read latency کم کرتی ہے۔

کیا میں موجودہ queries بدلے بغیر Prisma تیز کر سکتا ہوں؟

جی ہاں۔ Prisma Client initialization کے وقت ایک بار extension شامل کریں اور اپنا موجودہ Prisma query code unchanged رکھیں۔ Reads تیز چلیں گی جبکہ Prisma API، types اور schema وہی رہیں گے۔

کیا یہ production میں کام کرتا ہے؟

جی ہاں۔ یہ 137 E2E tests سے validate شدہ ہے اور production استعمال کے لیے ڈیزائن کیا گیا ہے۔ rollout سے پہلے اپنی Prisma version کے ساتھ compatibility verify کریں اور اپنے regression tests چلائیں۔

Prisma aggregations کیوں سست ہوتی ہیں؟

Aggregations اور groupBy اکثر fixed overhead (query processing اور result shaping) کو بڑھاتے ہیں اور بڑے intermediate result sets کی ضرورت ہو سکتی ہے۔ یہ extension SQL براہِ راست generate کر کے ان reads کو optimize کرتی ہے، جس سے aggregation-heavy endpoints میں عام طور پر latency کم ہوتی ہے۔

Prisma تیز کرنے کے لیے تیار؟

Prisma reads optimize کرنے والے developers میں شامل ہوں: 2–7× تیز (زیادہ سے زیادہ 53.5×)

Prisma-SQL انسٹال کریں GitHub پر دیکھیں