PgDog
An open-source Postgres proxy that pools connections, load-balances across replicas, and shards data across servers — without app code changes.
🔗 Visit PgDog
Description
As a database grows, a single Postgres server eventually can't keep up, and the usual fixes — connection pooling, read replicas, splitting data across multiple servers — normally mean rewriting parts of your application to know about all this new complexity. PgDog sits between your app and your databases as a transparent proxy, so your app keeps talking to what looks like one simple Postgres server while PgDog handles the pooling, load-balancing, and sharding behind the scenes.
PgDog is a Rust-based, open-source (AGPL-3.0) proxy offering transaction and session pooling similar to PgBouncer but with richer state management, application-layer load balancing across primary and replica instances, and automatic sharded query routing with cross-shard query aggregation. It supports multiple authentication methods (passwords, AWS RDS IAM, Azure Workload Identity, HashiCorp Vault), health checks with automatic failover, two-phase commit for atomic cross-shard writes, re-sharding via logical replication, and monitoring through OpenMetrics/OTEL endpoints. With 5,300+ GitHub stars and 1,100+ commits, it's actively developed with documented production deployments.
💬 Our review
The short version: if PgBouncer's connection pooling isn't enough anymore and you're staring down a real Postgres sharding project, PgDog is one of the few open-source tools that handles both pooling and sharding in a single proxy layer, without you rewriting your app's data access code.
Compared to PgBouncer, PgDog does everything PgBouncer does (transaction/session pooling) plus load balancing and automatic sharding — features PgBouncer simply doesn't have. Compared to fully managed alternatives (Citus on Azure, CockroachDB, or a cloud provider's built-in sharding), PgDog is free and self-hosted, but you own the operational responsibility of running and monitoring it, including its own health checks and failover logic. The two-phase commit support for atomic cross-shard writes is the detail that matters most for correctness — a lot of DIY sharding setups skip that and end up with subtle data-consistency bugs. As with any infrastructure-layer proxy, the real cost is operational: you're adding a new component that needs monitoring, and a bug in the proxy affects every query passing through it, so production adoption should come with real load testing first.
💰 Pricing
📊 Global score
🤖 AI-enriched data
100% open source (AGPL-3.0), auto-hébergé, aucun coût de licence
Pros
Pooling + load balancing + sharding dans un seul proxy
Two-phase commit pour les écritures cross-shard
Multiples méthodes d'authentification (Vault, IAM, Azure)
Monitoring OpenMetrics/OTEL intégré
Cons
Composant supplémentaire à opérer et monitorer soi-même
Sharding reste un projet d'infra non-trivial malgré l'outil
Communauté plus jeune que PgBouncer