PgBouncer Config Generator
Describe your application and PostgreSQL server, and this generator produces a ready-to-edit pgbouncer.ini with pool sizes derived from your real connection demand — plus warnings when the numbers cannot add up, such as session mode with more clients than the server has connections. Everything is calculated in your browser.
⚠ Transaction mode does not support session-level features: prepared statements (unless max_prepared_statements is set), LISTEN/NOTIFY, advisory locks held across statements, and SET at session scope. Disable server-side prepared statements in your driver, or set max_prepared_statements.
Do more than pgbouncer config generator — meet Chat2DB
Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.
How to use
- Enter your database connection details and choose a pool mode (transaction mode suits most web apps).
- Enter how many application instances you run, the connection pool size per instance, the database CPU core count and the server's max_connections.
- Copy the generated pgbouncer.ini, review the sizing warnings, and add the real SCRAM hash to userlist.txt on the server.
Frequently asked questions
Which PgBouncer pool mode should I use?
Transaction mode is the right default for web applications and serverless workloads: a server connection is held only for the duration of a transaction, so a handful of PostgreSQL connections can serve thousands of clients. Use session mode only when you need session-scoped features such as LISTEN/NOTIFY or session-level SET, and statement mode only for single-statement autocommit workloads.
How do I choose default_pool_size?
default_pool_size caps how many PostgreSQL connections PgBouncer opens per database and user pair. A common starting point is roughly two connections per CPU core plus a small allowance for disk concurrency; PostgreSQL cannot execute more concurrent queries than it has cores, so a larger pool mostly adds context switching. Start with the suggested value, then watch the cl_waiting column in SHOW POOLS and raise it only if clients queue.
Why is max_client_conn much larger than default_pool_size?
That gap is the entire point of a connection pooler. max_client_conn is how many application connections PgBouncer will accept — cheap, since idle clients hold no server connection in transaction mode — while default_pool_size is how many expensive PostgreSQL backends actually exist. A ratio of ten or more to one is normal.
