fix: reuse Prisma pools in production
Merged
PR
17h ago+50+50+01234567890123456789-5-5-0123456789
Description
Production skipped the global Prisma cache, so separate Next.js server bundles could each create a five-connection pool. Overlapping containers exhausted Supabase’s fifteen-session pool during deployment. Cache the base client in production too, with a regression test using the real adapter.
No linked issue. This promotes the same pool fix through staging while preserving production’s newer dependencies and entire Prisma tree.
Type of change
- Bug fix
- Documentation update
How Has This Been Tested?
- Local build
- CI build
- Lint
- Typecheck
- Unit tests: 2,214 passed
- Manual testing: local PostgreSQL dropped from fifteen to five connections for three module instances; two fixed processes peaked at ten, with 120/120 queries passing.
Screenshots (if applicable)
Not applicable.
Checklist
- Code follows project style
- Self-review completed
- Documentation updated
- Local lint, typecheck and tests pass
Notes for reviewers
The first replacement must avoid overlapping the old process’s duplicate pools. Publish and pull the verified image before stopping the old app, then restore rolling updates after verification. Dependencies, schema and query behavior are unchanged.