📌 Problem Description
The project is configured to use an enterprise-grade dual-pooler strategy in .env.example (using port 6543 with pgbouncer=true for DATABASE_URL transaction handling, and port 5432 for DIRECT_URL). However, looking at Next.js 14 App Router API boundaries (src/app/api/), the database context is susceptible to production degradation under concurrent loads.
In development (npm run dev) and serverless execution contexts, Next.js triggers frequent hot-reloads. If src/lib/prisma.ts initializes the PrismaClient singleton without anchoring it explicitly to a global production check structure (globalThis), every module compilation cycle or horizontal serverless spin-up will generate a fresh, detached database connection instance. This bypasses PgBouncer limits and crashes Supabase connections under load.
💡 Proposed Solution
Refactor the Prisma abstraction core singleton (src/lib/prisma.ts) to conform strictly to Next.js serverless orchestration specifications.
- Restructure initialization to intercept
globalThis execution memory space.
- Attach the structural conditional assignment to reuse the exact instantiation chain across runtime environments.
- Configure optimized lazy loading hooks for production routing boundaries.
🛠️ Technical Domain & Directory Focus
- Target File:
src/lib/prisma.ts
- Concepts Covered: Prisma Singleton Patterns, Next.js 14 Serverless Lifecycles, PgBouncer Pool Optimization.
📋 Acceptance Criteria
Please assign this issue to me I am NSOC contributor
📌 Problem Description
The project is configured to use an enterprise-grade dual-pooler strategy in
.env.example(using port6543withpgbouncer=trueforDATABASE_URLtransaction handling, and port5432forDIRECT_URL). However, looking at Next.js 14 App Router API boundaries (src/app/api/), the database context is susceptible to production degradation under concurrent loads.In development (
npm run dev) and serverless execution contexts, Next.js triggers frequent hot-reloads. Ifsrc/lib/prisma.tsinitializes thePrismaClientsingleton without anchoring it explicitly to a global production check structure (globalThis), every module compilation cycle or horizontal serverless spin-up will generate a fresh, detached database connection instance. This bypasses PgBouncer limits and crashes Supabase connections under load.💡 Proposed Solution
Refactor the Prisma abstraction core singleton (
src/lib/prisma.ts) to conform strictly to Next.js serverless orchestration specifications.globalThisexecution memory space.🛠️ Technical Domain & Directory Focus
src/lib/prisma.ts📋 Acceptance Criteria
PrismaClientinitialization chains during dev hot-reloads.Please assign this issue to me I am NSOC contributor