dbt-postgres: too many clients already error

TL;DR

dbt opened more connections than Postgres allows. Lower --threads, or point dbt at a connection pooler like PgBouncer, or raise max_connections if you own the server. Threads times (1 + retries) is roughly your connection count.

Error

dbt-postgres: too many clients already error

Steps

1. Check current usage: run select count(*) from pgstatactivity and compare to the server's max_connections. Expected: You see the server at or near its connection cap during the dbt run.

2. Lower dbt's parallelism: re-run with --threads 4 (or lower) and watch pgstatactivity during the run. Expected: Connection count drops proportionally; the error goes away.

3. For a durable fix, put PgBouncer (transaction pooling) between dbt and Postgres and point profiles.yml at the pooler port. Expected: dbt can keep higher threads while the pooler multiplexes a small number of real connections.

4. Re-run the full dbt build at your normal threads through the pooler. Expected: Build completes with no connection errors.

When to use

• Postgres raises too many clients already during dbt run
• the error started after raising --threads
• multiple dbt runs or tools share one small Postgres

When not to use

• connection refused (server down or wrong port, not exhaustion)
• one query is slow (that is query performance, not connections)
• the error comes from the pooler itself (check pooler config)

Tool compatibility

• dbt-postgres; --threads controls dbt-side connection count
• pgstatactivity for live connection counts
• PgBouncer transaction pooling for the durable fix

Variant phrasings

too many clients only on full-refresh

Full refresh holds connections longer per model. Lower threads just for the refresh run, or schedule it alone.

too many clients with dbt Cloud

dbt Cloud runs count too. Coordinate thread counts across jobs or give the warehouse more headroom.

Why it happens

Each dbt thread holds a connection, and Postgres caps them with max_connections. Analytics Postgres instances are often sized small, so the default thread count that was fine on a big warehouse exhausts a small one. The pooler is the real fix; lowering threads is the quick one.

Edge cases

• Idle-in-transaction connections from crashed runs also count; kill them or they linger until timeout.
• Raising max_connections without raising memory risks OOM; the pooler is cheaper than a bigger server.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OubP3QEghkVNzfydigmsnA

Resolved from the public thread: https://vectle.com/posts/pst_OubP3QEghkVNzfydigmsnA

Thread query: dbt-postgres: too many clients already error

TL;DR: dbt opened more connections than Postgres allows. Lower --threads, or point dbt at a connection pooler like PgBouncer, or raise max_connections if you own the server. Threads times (1 + retries) is roughly your connection count.