fix(db): revert statement_timeout startup options breaking pooled connections (#4284)

[waleedlatif1]

Summary

Brief description of what this PR does and why.

Fixes #(issue)

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• Other: ___________

Testing

How has this been tested? What should reviewers focus on?

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)

Screenshots/Videos

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
docs	Building	Preview, Comment	Apr 24, 2026 6:32am

[cursor]

PR Summary

Medium Risk
Touches database connection configuration used broadly by realtime and shared DB clients; while the change is small, it alters query/transaction timeout safeguards and could affect production behavior under slow or stuck queries.

Overview
Reverts the use of Postgres startup connection.options that set statement_timeout and idle_in_transaction_session_timeout on client creation.

Both the realtime socket DB client (apps/realtime/src/database/operations.ts) and the shared DB client (packages/db/index.ts) now create Postgres connections without these server-side timeout caps.

^{Reviewed by Cursor Bugbot for commit ccb5f1e. Configure here.}

[greptile-apps]

Greptile Summary

This PR removes the connection.options startup parameters (statement_timeout and idle_in_transaction_session_timeout) from both database clients (packages/db/index.ts and apps/realtime/src/database/operations.ts). These GUC startup parameters are incompatible with connection poolers (e.g., PgBouncer in transaction or statement mode), which cannot reliably propagate per-session settings across pooled connections.

Confidence Score: 5/5

Safe to merge — focused, correct revert with no logic changes beyond removing incompatible startup parameters.

The change is a minimal, targeted removal of two startup GUC options that were documented as incompatible with connection poolers. Both files are treated consistently. The only remaining finding is a P2 suggestion to re-add timeout protection at the database role level, which does not block merge.

No files require special attention.

Important Files Changed

Filename	Overview
packages/db/index.ts	Removed connection.options startup parameters (statement_timeout, idle_in_transaction_session_timeout) and associated JSDoc; fixes pooled-connection compatibility at the cost of application-level runaway query protection.
apps/realtime/src/database/operations.ts	Same removal of connection.options startup parameters from the realtime socket database client; consistent with the change in packages/db/index.ts.

Sequence Diagram

sequenceDiagram
    participant App as Application
    participant Pool as Connection Pooler (PgBouncer)
    participant PG as PostgreSQL

    Note over App,PG: Before this PR (broken with pooler)
    App->>Pool: Connect + startup options (-c statement_timeout=90000)
    Pool--xApp: Error / rejected (pooler cannot forward session GUCs)

    Note over App,PG: After this PR (fixed)
    App->>Pool: Connect (no startup options)
    Pool->>PG: Forward pooled connection
    PG-->>Pool: Connection established
    Pool-->>App: Connection ready
    App->>PG: Query
    PG-->>App: Result

Loading

_{Reviews (1): Last reviewed commit: "fix(db): revert statement_timeout startu..." | Re-trigger Greptile}

[greptile-apps]

Runaway query protection now absent at the application layer

With statement_timeout and idle_in_transaction_session_timeout removed, there is no longer a backstop against hung queries or transactions that hold row locks indefinitely. Under connection exhaustion (e.g., a blocked query monopolising all 30 slots), the pool can stall completely. The pooler-incompatibility issue is real and worth fixing, but consider re-applying the same limits at the database role level so they apply regardless of how the client connects:

ALTER ROLE <app_user> SET statement_timeout = '90s';
ALTER ROLE <app_user> SET idle_in_transaction_session_timeout = '90s';

This survives connection poolers and requires no client-side configuration.