Skip to content

No Prisma/Postgres connection-pool sizing — exhaustion under multi-worker load #64

Description

@cybermax4200

Why this matters now: With 5+ background sweepers/workers plus the API all sharing one Postgres, connection storms during traffic spikes will cascade into 5xx and stuck jobs.

Problem / What: There is no connection_limit / pool configuration on the Prisma datasource or the raw $queryRaw usage. BullMQ workers, the audit drainer, and HTTP handlers each open Prisma connections; default pool sizing (num_physical_cpus*2+1) is per-client and not globally bounded, so total Postgres connections can exceed max_connections under load.

Key Challenges: Centralizing a single Prisma client with an explicit connection_limit, measuring peak concurrency across workers, and ensuring long-running raw $queryRaw callers (audit, analytics) participate in the pool.

Acceptance Criteria:

  • Total open Postgres connections stay under a configured ceiling under a load test simulating peak concurrent workers + requests.
  • Connection acquisition is instrumented/logged on saturation.

Relevant files/functions: src/utils/prisma.ts, prisma/schema.prisma (datasource), src/services/auditService.ts, src/config/default.ts.

Out of scope: Read-replica separation.

Labels: advanced, ops, reliability

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions