> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dbhost.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Connection limits and query timeouts

> How DBHost's per-database PgBouncer server connection cap (plan default, adjustable up to the plan maximum) and the three fixed query timeout profiles work.

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:

* Dashboard: **Performance** tab → **Connection limit** → **Change limit**
* API: [`POST /api/v1/databases/{id}/connection-limits`](/api-reference/databases/connection-limits)
* CLI: `dbhost databases limits-set <id> <cap> --idempotency-key KEY`

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:

| Profile | Statement | Lock wait | Idle in transaction |
| - | -: | -: | -: |
| **Standard** | 60 s | 10 s | 30 s |
| **Balanced** | 30 s | 3 s | 15 s |
| **Short** | 15 s | 1 s | 5 s |

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`](/api-reference/databases/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](/guides/direct-migrations), which has its own
statement and lock timeouts.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.