iDBQuery prend-il en charge le pooling de connexions pour ma base de données ?

iDBQuery est conçu pour être un client bien élevé de votre base de données. Il ouvre des connexions en lecture seule pour exécuter le SQL qu'il génère, renvoie le résultat et ne maintient pas un grand nombre de connexions inactives ouvertes. Lorsque vous souhaitez une couche de contrôle supplémentaire, vous pouvez pointer iDBQuery vers un pooler de connexions plutôt que vers la base directement :

• PgBouncer ou PgCat devant PostgreSQL.
• Un point de terminaison mutualisé cloud — le pooler de Supabase, la chaîne de connexion mutualisée de Neon, RDS Proxy, et similaires.
• ProxySQL ou équivalent devant MySQL.

Du point de vue d'iDBQuery, le pooler n'est que l'hôte auquel il se connecte : la configuration est donc identique à une connexion à la base — vous fournissez le point de terminaison du pooler et les identifiants.

En quoi cela aide : les requêtes analytiques peuvent être irrégulières, et les acheminer via un pooler protège les limites de connexions de votre base principale, en particulier pour les bases serverless où les connexions sont précieuses. Associé au fait de pointer iDBQuery vers une réplica de lecture et de lui donner un utilisateur en lecture seule, vous obtenez une analytique qui ne menace jamais la stabilité de la production.

Comme iDBQuery agrège au niveau de la base et ne renvoie que le résultat — un chiffre, un graphique ou un tableau de bord — plutôt que de diffuser des tables brutes, son empreinte sur votre base reste faible, même à mesure que davantage de personnes posent des questions.