GitLab Rails ↔ PgBouncer: Can Transaction-Mode Pooling Work with Rails Prepared Statements?

Goal: Validate PgBouncer Mode Compatibility with GitLab Rails

We need to determine whether the GitLab Rails application can safely operate with PgBouncer in transaction‑mode while retaining its default prepared‑statement behavior, or if session‑mode is required. The decision hinges on the interaction between Rails’ prepared statements and PgBouncer’s pooling strategy.

Key Constraints

• GitLab’s database.yml defaults to prepared_statements: true.
• Transaction‑mode PgBouncer does not preserve prepared statements unless prepared_statements: false is set.
• Session‑mode preserves prepared statements but ties each client to a single backend connection, increasing PostgreSQL connection usage.

Unresolved Decision

Which PgBouncer mode should be adopted for a typical GitLab deployment that prioritizes scalability without compromising statement execution correctness?

1. Can transaction‑mode be used if the Rails prepared_statements flag is disabled, and what impact does this have on query performance and caching?
2. Does session‑mode reliably prevent “prepared statement does not exist” errors after a GitLab upgrade, and how does it affect PostgreSQL connection counts under load?
3. What monitoring or verification steps are required to confirm that the chosen mode remains compatible across future GitLab releases?