TL;DR
setConfig({ database: { ... } }) accepts host/port/credentials but no pool-tuning options. Downstream consumers (Stacks via @stacksjs/database — see stacksjs/stacks#1876 D-3) have no path to set pool size, idle timeout, or retry-on-disconnect, so a long-running server hits "max connections" with no actionable knob.
Filing as a tracker so consumers know the API surface is on the roadmap.
Today
```ts import { setConfig } from 'bun-query-builder'
setConfig({ dialect: 'postgres', database: { database: 'app', host: 'localhost', port: 5432, username: 'app', password: '...', }, }) ```
There's no way to tune the underlying Bun SQL pool. Bun's drivers (`Bun.SQL` etc.) accept pool options natively — they're just not threaded through the qb config layer.
Proposed shape
Add an optional `pool` block to `DatabaseConfig`:
```ts export interface DatabaseConfig { database: string username: string password: string host: string url?: string port: number
/** Connection pool tuning. All fields optional with sensible defaults. / pool?: { /* Max connections in the pool. Default: driver-specific (typically 10). / max?: number /* Min idle connections held open. Default: 0. / min?: number /* Idle timeout in milliseconds before a connection is released. / idleTimeoutMs?: number /* Connection-acquisition timeout in milliseconds. / acquireTimeoutMs?: number /* Whether to enable automatic reconnect on broken connection. Default: true. */ autoReconnect?: boolean } } ```
Pass through to the underlying `Bun.SQL` / `Bun.sql` constructor at connection-establish time.
Stretch: leak detection
A separate, configurable knob:
```ts pool?: { ... /**
- When set, log a warning whenever a connection is held for
- longer than this many milliseconds without being released.
- Captures the stack of the original checkout to make it
- actionable — most pool leaks come from a forgotten `await`
- deep in a request handler. */ leakWarnAfterMs?: number } ```
This catches the common "long-running server slowly exhausts its pool" pattern in dev without forcing every user to wire up Pino-or-equivalent log mining.
Why now
Stacks tried to land a pool-config exposure in #1876 D-3 but the qb layer doesn't surface the fields — closed-loop fix needs to land here first. No urgency on shipping, just want a stable API to depend on downstream.