fix(db): reduce connection pool sizes to prevent exhaustion

[waleedlatif1]

Summary

• Reduced main DB pool from 30 to 10 connections per process
• Reduced socket DB pool from 15 to 10 connections per process
• Prevents connection exhaustion under load when multiple service instances compete for the same pool

Type of Change

• Bug fix

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[cursor]

You have used all Bugbot PR reviews included in your free trial for your GitHub account on this workspace.

To continue using Bugbot reviews, enable Bugbot for your team in the Cursor dashboard.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview, Comment	Mar 18, 2026 9:11am

[waleedlatif1]

@greptile

[greptile-apps]

Greptile Summary

This PR reduces the Postgres connection pool sizes to prevent exhaustion in multi-instance deployments — the main DB pool drops from 30 → 10 (packages/db/index.ts) and the socket DB pool from 15 → 10 (apps/sim/socket/database/operations.ts). Both pools connect to the same DATABASE_URL, so the effective per-process footprint is 20 connections (10 main + 10 socket), not 10.

Key considerations:

• The main pool reduction is aggressive (−67%). Without load-testing evidence it is unclear whether 10 concurrent connections is enough at peak throughput; if the app regularly issues more than 10 parallel queries, callers will queue and risk timing out.
• Both pools are now symmetrically capped at 10 — previously the socket pool was half the main pool (15 vs 30), which may have been intentional to deprioritise socket writes.
• Neither pool sets max_lifetime, which can allow stale long-lived connections to accumulate; this is pre-existing but worth addressing as part of this work.
• Manual testing only — no automated load or stress tests were added to validate the new limits hold under realistic concurrency.

Confidence Score: 3/5

• Safe to merge with caution — the intent is correct, but the aggressive pool reduction lacks load-test validation and may introduce latency or timeouts under high concurrency.
• The logic for reducing pools to prevent DB exhaustion in multi-instance deployments is sound. However, a 67% reduction in the main pool (30 → 10) with only manual testing creates meaningful risk of under-provisioning at peak load. The combined per-process total is still 20 (main + socket to the same DB), which should be documented. No automated tests were added.
• Both changed files are low-risk individually, but packages/db/index.ts deserves attention due to the magnitude of the main pool reduction.

Important Files Changed

Filename	Overview
packages/db/index.ts	Reduced main Postgres connection pool from 30 to 10. Change is intentional and targeted; main concern is whether 10 is sufficient under peak concurrent load without load-testing data.
apps/sim/socket/database/operations.ts	Reduced socket-specific Postgres pool from 15 to 10. Both pools now share the same cap, contributing 10+10=20 connections per process to the same database.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Service Instance N] --> B[Main DB Pool\nmax: 10\nidle_timeout: 20s\nconnect_timeout: 30s]
A --> C[Socket DB Pool\nmax: 10\nidle_timeout: 10s\nconnect_timeout: 20s]
B -->|up to 10 connections| D[(PostgreSQL\nDATABASE_URL)]
C -->|up to 10 connections| D
E[Service Instance 1] --> F[Main DB Pool\nmax: 10]
E --> G[Socket DB Pool\nmax: 10]
F -->|up to 10 connections| D
G -->|up to 10 connections| D
note1[Per instance: 20 connections max\nWith N instances: 20×N total] -.-> D

Loading

_{Last reviewed commit: "fix(db): reduce conn..."}