connect_timeout defines how long ParadeDB/PostgreSQL will wait when opening a new client connection before aborting.
connect_timeout (seconds) tells ParadeDB/PostgreSQL how long to attempt a TCP handshake and authentication before giving up. A low value fails fast; a high value tolerates slow networks.
Add connect_timeout=<seconds>
to any libpq-style URI or keyword/value string. Example:
psql "host=db.prod port=5432 dbname=shop user=app connect_timeout=5"
Yes.Use -d
or -h
/-p
flags together with the parameter:
psql -h db.prod -p 5432 -U app -d shop "connect_timeout=5"
Increase the value for cross-region traffic, overloaded servers, or VPN links. Decrease it inside low-latency data centers to fail over quickly.
If omitted, libpq waits 15 seconds (psql) or the driver default. ParadeDB inherits this from PostgreSQL.
No. It influences only the initial handshake.Query execution timeouts use statement_timeout
.
• Document the chosen timeout in infrastructure code.
• Keep it under your load-balancer health-check interval.
• Monitor failed logins for spikes indicating an overly low value.
const { Pool } = require('pg');
const pool = new Pool({
connectionString: 'postgres://app:@db.prod:5432/shop',
connectionTimeoutMillis: 5000, // 5 seconds
});
Block the port with a firewall rule and run your client; it should error in ≈timeout seconds.
.
Yes. All drivers using libpq respect the parameter, even when ParadeDB runs on Neon or RDS.
Only when the pool opens new sockets. Established pooled connections ignore it.
The driver falls back to its default (15 s in libpq).