PgDog - un outil pour shard Postgres sans extension supplémentaire

 (github.com/pgdogdev)
4 points par GN⁺ 2025-05-29 | 1 commentaires | Partager sur WhatsApp
  • Pooler de transactions et gestionnaire de réplication logique pour PostgreSQL développé en Rust, offrant des fonctions d’extension horizontale et d’automatisation du sharding
  • Permet de sharder facilement une base de données PostgreSQL sans extension, avec une conception optimisée pour gérer des centaines de bases et des centaines de milliers de connexions
  • Load balancer DB fonctionnant à la couche applicative (OSI 7), capable de router automatiquement les requêtes SELECT vers les réplicas et les autres vers le primaire
  • Prend en charge le pooling de transactions/sessions comme PgBouncer, tout en analysant les requêtes pour les router automatiquement vers le bon shard et en fusionnant les résultats
  • Utilise COPY et la réplication logique pour répartir automatiquement les données entre les shards ou sharder une base existante sans interruption
  • La configuration peut être définie simplement avec des fichiers TOML, avec reconfiguration à chaud
  • Contrairement à Citus, qui s’appuie sur des extensions Postgres, il s’agit d’un proxy externe à la base, donc utilisable aussi sur RDS, Cloud SQL, etc.

Présentation du projet et principaux atouts

  • PgDog est une solution open source qui prend en charge l’easy sharding des bases PostgreSQL, la réplication logique, le pooling de transactions et la répartition de charge L7 pour une extension horizontale complète
  • Développé en Rust, il offre hautes performances et sécurité
  • Sans installation d’extension, un simple déploiement de proxy suffit à mettre en place sharding, distribution des données, reprise après incident et load balancing flexible
  • Contrairement à des produits concurrents (par ex. PgBouncer, PgCat), il prend aussi en charge le sharding automatique et la réplication logique, avec comme point fort la modification de configuration en production et le monitoring en temps réel

Fonctionnalités principales

Répartition de charge (Load Balancer)

  • PgDog est un proxy au niveau applicatif de la couche 7 OSI, qui répartit les requêtes entre plusieurs réplicas et nœuds primaires PostgreSQL afin d’éviter les pannes et la surcharge
  • Plusieurs stratégies sont proposées : round robin, aléatoire, nombre minimal de connexions, etc.
  • Il distingue les types de requêtes pour envoyer automatiquement les SELECT vers les réplicas et les autres requêtes d’écriture vers le nœud primaire
  • Il effectue des health checks et un failover automatique en cas d’incident, garantissant la disponibilité même en cas d’erreurs réseau ou de panne matérielle

Pooling de transactions

  • Comme PgBouncer, PgDog prend en charge le pooling de transactions et de sessions pour gérer efficacement les ressources de connexion, permettant d’absorber des centaines de milliers de clients avec un petit nombre de connexions backend

Sharding

  • Analyse directement la syntaxe des requêtes pour extraire la clé de sharding et appliquer l’algorithme de routage optimal
  • Prend aussi en charge les requêtes cross-shard entre plusieurs bases shardées, fusionne les résultats en mémoire puis les transmet de façon transparente au client
  • Lors de l’exécution de la commande COPY, prend en charge la répartition multishard des données via parsing CSV, pratique pour les chargements volumineux
  • S’appuie sur le protocole de réplication logique de PostgreSQL pour une synchronisation de fond sans interruption, avec ajout et extension de shards en temps réel en production

Monitoring

  • Prend en charge à la fois une base d’administration de style PgBouncer et un endpoint OpenMetrics
  • Fournit des exemples pour le monitoring externe et les dashboards, notamment avec Datadog

Configuration et runtime

  • Environnements principaux : Kubernetes (avec chart Helm), Docker et environnement local (build Rust), pour un déploiement et des tests faciles
  • En règle générale, il suffit de rédiger 2 fichiers de configuration (pgdog.toml, users.toml) pour mettre en place un environnement minimal de sharding et d’exploitation basé sur les utilisateurs
  • La plupart des paramètres peuvent être modifiés en temps réel et appliqués dynamiquement sans redémarrer le processus

Performances et licence

  • PgDog est un proxy réseau asynchrone haute performance basé sur Rust et Tokio, conçu pour minimiser les mouvements de données et limiter la dégradation des performances
  • Les résultats de benchmark sont fournis dans la documentation officielle pour servir de référence de performance
  • Distribué sous licence open source AGPL v3, il est entièrement ouvert à l’usage interne en entreprise et à la personnalisation privée
  • En revanche, les entreprises qui fournissent un service de cloud public doivent partager le détail de leurs modifications de code

État du projet et contribution

  • Le projet en est actuellement à un stade précoce et recommande surtout une adoption par les early adopters ; la stabilisation des fonctionnalités progresse régulièrement
  • Des tests et benchmarks par fonctionnalité sont menés en continu
  • Les contributions de la communauté open source sont les bienvenues ; voir les Contribution Guidelines pour plus de détails

Conclusion

  • PgDog apporte une excellente solution aux équipes de développement et aux entreprises qui ont besoin de scalabilité horizontale, haute disponibilité et sharding automatique pour PostgreSQL en environnement de production
  • Son grand avantage est de pouvoir être déployé rapidement et personnalisé sans extension supplémentaire ni infrastructure complexe

À lire aussi

1 commentaires

 
GN⁺ 2025-05-29
Avis Hacker News

  • En saluant Lev, il explique qu’il est en train de comparer PgDog à une solution développée en interne pour le sharding d’une base Postgres de 40 To, et mentionne qu’il a besoin d’une solution qui fonctionne comme Vitess for PostgreSQL ; il insiste sur le fait qu’au-delà de la fonction de scatter-gather, il faut aussi une gestion de configuration basée sur quelque chose comme etcd, le découpage de shards, ainsi que des transactions en best-effort pour appliquer des changements de schéma sur l’ensemble des shards ; il demande aussi un retour d’expérience sur la réécriture de requêtes avec pg_query.rs, partage le fait qu’il a trouvé cela difficile à cause de l’immuabilité des types AST et de l’absence de deep clone, et indique qu’il utilise finalement la crate sqlparser avec prise en charge du pattern Visitor, tout en développant en side project un changement de schéma online pour PG basé sur les shadow tables et la réplication logique

    • Heureux de la proposition de collaboration, il partage ses coordonnées et explique que la gestion de configuration peut déjà être résolue avec K8s ou divers outils de CD, et qu’il est possible de synchroniser le rechargement de la configuration de PgDog ; il précise que les changements de schéma sur tous les shards via des transactions en best-effort fonctionnent déjà, que des changements de schéma idempotents sont préférables, mais qu’un commit en deux phases est aussi envisagé en cas d’échec ; il ajoute que le découpage de shards est possible via la réplication logique, en citant une expérience sur plus de 10 To chez Instacart, puis partage la procédure consistant à ouvrir un slot de réplication, restaurer sur N instances, supprimer les données dont le numéro de shard ne correspond pas, puis resynchroniser via réplication logique ; il évoque aussi l’idée d’exploiter la réplication logique de Pg 17 depuis une streaming replica pour paralléliser le split, ainsi qu’une méthode consistant à faire directement un COPY des données via des tables externes ; il souligne que pg_query.rs semble désormais mutable et qu’il l’utilise activement ces derniers temps pour réécrire et générer des requêtes, son grand avantage étant d’être basé à 100 % sur le parseur Postgres, avec des fonctionnalités de « deparse » un peu partout qui ouvrent la voie à des traitements complexes

  • Question sur le fait que, s’il existait un Vitess for Postgres, Yugabyte ne remplirait pas déjà ce rôle

  • Même si le cœur des fonctionnalités paraît modeste, il estime que PgDog apporte un énorme avantage en permettant de sortir cette logique du code et de séparer les lectures vers des read replicas et les écritures vers le primaire ; comme beaucoup d’applications ne gèrent pas directement la séparation R/W, le fait de la traiter au niveau du proxy lui a déjà apporté par le passé de gros gains de performance, et il félicite le projet

    • Réponse indiquant que cette fonctionnalité est déjà disponible dans pgcat, avec partage du lien pgcat

    • Il partage qu’ils faisaient de la séparation R/W chez Instacart avec Makara, mais que devoir réimplémenter la même chose dans plusieurs environnements, comme Python ou Go, était assez fastidieux

  • Il juge le projet impressionnant, tout en gardant une certaine réserve vis-à-vis du sharding entièrement automatisé ; en général, le sharding se fait aux frontières de tenancy, et il préfère qu’il y ait une certaine friction lorsqu’on franchit cette frontière ; comme les jointures inter-shards ne sont pas comparables aux jointures intra-shard en termes de performances, de mémoire et de CPU, il estime qu’il faudrait le rendre plus explicite ; cela dit, il ne doute pas du projet lui-même et pense qu’il aura de nombreux cas d’usage

    • En demandant pourquoi on voudrait volontairement de la friction, il ajoute que les problèmes de performance des jointures inter-shards sont en général bien compris et peuvent être suivis avec des métriques temps réel ; au final, les deux approches sont nécessaires, et l’alternative consistant à faire les jointures dans le code applicatif n’est pas très souhaitable

  • Il suit PgDog de près et le trouve très impressionnant, félicite l’équipe pour la sortie et espère le voir continuer à progresser

    • Il répond qu’un voyage de 15 ans ne fait que commencer

  • Selon lui, l’attrait principal réside dans le traitement des requêtes distribuées tout en conservant la transparence et la compatibilité au niveau de la couche réseau ; les limitations actuelles de la documentation lui paraissent naturelles, et il s’attend à ce que des compromis soient nécessaires ; il est curieux de voir comment cela sera résolu et propose de participer à la discussion si elle continue

  • Il mentionne que, dans une solution comme PgDog, la plus grande difficulté est de bien gérer jusqu’au dernier 1 % les requêtes complexes sur des données shardées — ou bien de détecter les requêtes anormales — ainsi que de garantir pleinement l’isolation et la cohérence

  • En voyant la documentation, la première chose qu’il a vérifiée a été la prise en charge des Unique Index, mais il regrette qu’ils ne soient pas encore supportés, car cela nécessite encore de la réécriture de requêtes et un moteur d’exécution séparé ; malgré cela, il voit du potentiel et reste optimiste

    • Il répond qu’en lot de consolation, la génération de clés primaires uniques sur tous les shards est déjà prise en charge, et partage la documentation correspondante ; il explique que l’implémentation d’index uniques cross-shard est coûteuse, car elle exige des vérifications sur toutes les requêtes, et laisse l’idée ouverte

  • Il souligne que c’est le projet Postgres le plus intéressant qu’il ait vu depuis des années ; selon lui, les benchmarks fournis semblent surtout couvrir le connection pooling de base, et il aimerait savoir ce qu’il en est lorsque l’analyse de requêtes ou les jointures inter-shards entrent en jeu

    • Réponse expliquant que le parseur de requêtes est mis en cache et qu’avec des prepared statements ou des placeholders, le coût supplémentaire se limite pratiquement à un verrou et à une recherche dans une table de hachage ; pour les jointures inter-shards, le coût de traitement peut augmenter si les filtres ne sont pas optimaux, et il peut même devenir nécessaire de paginer sur disque lorsque l’ensemble de résultats est volumineux ; l’équipe se concentre d’abord sur l’OLTP et cherche à pousser les jointures au maximum, mais s’attend à ce que la demande pour les jointures inter-shards augmente bientôt

  • Félicitations pour le lancement, qu’il considère comme une innovation indispensable pour la scalabilité de Postgres

  • Il trouve le projet extrêmement solide et félicite l’équipe pour la sortie

    • Il souligne que c’est le fruit de plusieurs années de travail