fix: reuse Prisma pools across production bundles
Merged
PR
1d 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.
Type of change
- Bug fix
- Documentation update
How Has This Been Tested?
- Local build
- CI build
- Lint
- Typecheck
- Unit tests: 2,156 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.
Summary by CodeRabbit
- Bug Fixes
- Production server bundles now reuse a shared database client, helping limit duplicate database connections.
- Documentation
- Updated self-hosting guidance with connection-pool defaults, connection budgeting examples, and recommendations for replacing releases that do not reuse database clients.