Does iDBQuery support connection pooling for my database?
Yes. iDBQuery manages its database connections efficiently and can connect through a connection pooler such as PgBouncer or a cloud pooled endpoint, so it doesn't overwhelm your database. It opens read-only connections, runs the query, and returns the result.
iDBQuery is designed to be a well-behaved client of your database. It opens read-only connections to run the SQL it generates, returns the result, and doesn't hold large numbers of idle connections open. When you want an extra layer of control, you can point iDBQuery at a connection pooler instead of the database directly:
- PgBouncer or PgCat in front of PostgreSQL.
- A cloud pooled endpoint — Supabase's pooler, Neon's pooled connection string, RDS Proxy, and similar.
- ProxySQL or comparable in front of MySQL.
From iDBQuery's perspective the pooler is just the host it connects to, so setup is the same as connecting to the database — you supply the pooler's endpoint and credentials.
Why this helps: analytics queries can be spiky, and routing them through a pooler protects your primary database's connection limits, especially for serverless databases where connections are precious. Combined with pointing iDBQuery at a read replica and giving it a read-only user, you get analytics that never threatens production stability.
Because iDBQuery aggregates on the database and returns only the result — a number, chart, or dashboard — rather than streaming raw tables out, its footprint on your database stays small even as more people ask questions.
Updated 2026-06-22