Skip to main content
Every DBHost database sits behind PgBouncer in transaction pooling mode. Two per-database settings shape how your queries share the PostgreSQL host: the server connection cap and the query timeout profile. Neither is a CPU, memory or disk quota; customer databases share the same host resources.

​
Server connection cap

The cap is the number of PostgreSQL server connections PgBouncer may open for your database at the same time.
  • Default: Free 2, Pro 3, Business 4; development databases start at 2
  • Range: 2 up to the plan maximum: Free 4, Pro 12, Business 24
  • Shared: by every role on the database, including additional roles
A cap that is already above your plan’s maximum, for example after a plan change, is kept. You can lower it, but not raise it further. Many application clients can connect to PgBouncer at once. When all server connections are busy, new transactions wait in PgBouncer’s queue until one is free. The database detail page shows current server connections and waiting clients, and warns at 80% of the cap or when clients are waiting. Raise the cap when clients wait regularly. Lower it to leave more room for other workloads on a busy app. To change it: The dashboard, API and CLI accept every value from 2 up to your plan’s maximum (caps above 8 through the CLI need CLI 0.3.8 or newer). Lowering the cap does not disconnect existing sessions. A request above your plan’s maximum returns 403 CONNECTION_CAP_ABOVE_PLAN. An increase within the plan can still be refused with 503 CLUSTER_CAPACITY_FULL when measured use on the shared host is close to full; the cap is then unchanged. API and CLI access require Pro or Business.

​
Query timeout profiles

A profile sets PostgreSQL defaults for new sessions on your database. There are three fixed profiles: Use Standard for most apps, Balanced for interactive web traffic, and Short when slow queries should fail fast. Running transactions are not interrupted; PgBouncer moves to the new defaults as server connections are replaced. If a role has its own timeout overrides, those overrides still apply, and the dashboard points this out. To change the profile:
  • Dashboard: Performance tab → Query timeouts → Change timeout profile
  • API: POST /api/v1/databases/{id}/query-timeouts
  • CLI: dbhost databases timeouts-set <id> <standard|balanced|short> --idempotency-key KEY
Long migrations that exceed these limits can run through the direct migration connection, which has its own statement and lock timeouts.