PgBouncer fonctionne. C’est indéniable. Mais quiconque a migré une application existante vers un pooler de connexions PostgreSQL connaît le prix à payer : du code à réécrire, des fonctionnalités à abandonner, des compromis douloureux. C’est exactement ce constat qui a poussé l’équipe de PgDog à construire un nouvel outil plutôt que d’adopter l’existant.
Le problème des poolers de connexions PostgreSQL classiques
Les poolers comme PgBouncer ou RDS Proxy respectent la philosophie UNIX : faire une seule chose, et la faire bien. C’est une force, mais aussi une limite. En réutilisant les connexions entre clients, ces outils introduisent ce qu’on appelle une fuite d’abstraction : vous ajoutez une couche d’infrastructure qui change la façon dont votre application dialogue avec la base de données.
En pratique, cela se traduit par deux contraintes majeures.
Les commandes SET deviennent dangereuses
Lorsqu’un pooler réutilise une connexion, l’état de session d’un client peut contaminer celui d’un autre. Si vous utilisez SET pour définir un timeout ou configurer le Row Level Security (RLS), ce paramètre peut fuir vers un autre client.
Le scénario bénin : une requête lente s’exécute trop longtemps. Le scénario grave : votre politique RLS cesse de fonctionner et des lignes disparaissent silencieusement. La recommandation classique est donc de ne plus utiliser SET. Autrement dit, de renoncer à une fonctionnalité native de PostgreSQL.
LISTEN/NOTIFY est incompatible avec le mode transaction
Les commandes LISTEN et NOTIFY implémentent un système pub/sub directement dans PostgreSQL. C’est pratique, ça évite d’ajouter Redis ou SQS à votre stack. Mais en mode transaction, les poolers classiques ne savent pas les gérer. Résultat : la plupart des équipes abandonnent cette fonctionnalité dès qu’elles ajoutent un pooler.
Ce que PgDog fait différemment
Un parseur SQL embarqué pour les commandes SET
PgDog intègre un parseur SQL capable de détecter les instructions SET, d’extraire les variables et leurs valeurs, et de les stocker côté client dans le proxy. Avant d’exécuter une requête, PgDog vérifie que l’état de la connexion serveur correspond à celui du client. Si ce n’est pas le cas, il synchronise les variables manquantes via du query pipelining, en un seul aller-retour réseau.
L’impact sur les performances est limité, et vous conservez l’accès à une fonctionnalité PostgreSQL sans modifier votre code applicatif.
LISTEN/NOTIFY géré nativement et en multi-processus
C’est le choix d’architecture le plus original de PgDog. L’outil gère LISTEN et NOTIFY en interne, en déplaçant les messages entre les différentes instances du proxy. Pour le client, PgDog semble être le broker. En réalité, c’est toujours PostgreSQL qui joue ce rôle.
Concrètement, PgDog utilise le broadcast channel de Tokio pour router les messages entre clients dans un même processus. Pour les déploiements multi-conteneurs (production Kubernetes par exemple), il maintient une connexion dédiée vers PostgreSQL pour relayer tous les LISTEN et NOTIFY. PgDog agit ainsi comme un proxy pub/sub, en utilisant PostgreSQL comme broker réel.
L’équipe annonce également avoir corrigé des comportements transactionnels de NOTIFY qui avaient causé des incidents de production chez certains utilisateurs.
Un moteur multithreadé sur Tokio en Rust
PgDog est écrit en Rust et s’appuie sur Tokio, un runtime async multithreadé. Chaque client est géré par une tâche async indépendante. Cela permet d’exploiter plusieurs CPU dans un seul processus, sans fragmenter le pool de connexions.
Avec PgBouncer, chaque processus possède son propre ensemble de connexions PostgreSQL. Si un processus est saturé, les clients qui y sont attachés attendent. PgDog évite cette situation en centralisant la gestion des connexions dans un processus multithreadé capable d’absorber des pics de charge sans dépendre d’un autoscaling externe.
Les bénéfices concrets :
- Meilleure utilisation des connexions serveur grâce à un pool partagé entre tous les threads
- Réponse plus rapide aux pics de trafic sans attendre un scale-out
- Observabilité simplifiée : une seule source de métriques et de health checks
- Pas de complexité cachée côté noyau Linux ou plan de contrôle AWS
Quelques points à garder en tête
PgDog est présenté comme open source et libre d’utilisation. L’équipe indique qu’il tourne en production depuis plus d’un an, à un débit de 2 millions de requêtes par seconde. Ce sont des chiffres issus de l’équipe elle-même : des benchmarks indépendants et des retours terrain d’utilisateurs extérieurs restent à documenter.
L’identité complète de l’équipe et le modèle de gouvernance du projet ne sont pas détaillés dans la documentation publique disponible à ce jour. C’est un point à surveiller pour évaluer la pérennité du projet sur le long terme.
Par rapport aux autres alternatives comme Supavisor ou Pgpool-II, PgDog ne publie pas encore de benchmark comparatif public. La comparaison reste donc qualitative pour l’instant.
Ce qu’il faut retenir
- PgDog est un pooler PostgreSQL open source qui résout les fuites d’abstraction des outils classiques (PgBouncer, RDS Proxy) sans forcer à réécrire le code applicatif.
- Son parseur SQL embarqué préserve le comportement des commandes
SETet évite la contamination d’état entre clients. - La gestion native de
LISTEN/NOTIFYen mode multi-processus est le choix d’ingénierie le plus distinctif du projet. - L’architecture Rust/Tokio multithreadée vise une meilleure utilisation des ressources et une observabilité simplifiée.
- Le projet est récent côté visibilité publique : les benchmarks indépendants et les retours d’adoption à grande échelle restent à venir.
Si vous gérez une infrastructure PostgreSQL en production et que vous avez déjà renoncé à RLS ou à LISTEN/NOTIFY à cause d’un pooler, PgDog mérite clairement un coup d’oeil. N’hésitez pas à partager votre expérience ou à poser vos questions en commentaire, ou à suivre le blog pour les prochaines analyses.
Sources
- PgDog – Why we built yet another Postgres connection pooler : article officiel de l’équipe PgDog, source primaire de référence pour cet article.