PgDog is an open source connection pooler, load balancer, and sharding proxy for PostgreSQL. It's Postgres-compliant, fast, secure and built in the open by a community of database engineers.
No reviews yetBe the first to leave a review for PgDog
Viktor.comAn AI coworker that actually does the work
Promoted
2M qps in production is the number that actually matters here. schema migrations on a sharded setup - does PgDog coordinate an ALTER TABLE across all shards atomically, or is sequencing that still on the DBA?
Congrats on the launch. One thing that would help teams adopt this faster is a built-in dashboard or web UI for live monitoring of pool stats, query latency, and shard distribution. Most teams using pgBouncer end up bolting on tools like pgwatch2 or custom Grafana setups, so having something more turnkey would be a real differentiator.
2M qps in production is a real number, not a launch-day claim. the part I'd actually worry about with transparent sharding is cross-shard joins and multi-shard transactions, since that's usually where these proxies either quietly fall back to something expensive or just reject the query outright. does pgdog handle that at the protocol level too, or is there a class of queries you tell people to just not run against a sharded setup
Report
Lev — 2M qps across production deployments for over a year is a real data point, not a launch-day claim (as Gal put it below). WinBidIQ's Postgres load is basically bimodal: a nightly batch job writes tens of thousands of updated federal opportunity rows scraped daily, then daytime traffic is almost all reads — scoring, dashboard, search — from SaaS users. Right now we just add read replicas and hope the app connects to the right one. Does PgDog handle read/write splitting itself, routing reads to replicas automatically, or is that still a decision the app has to make before the query ever reaches PgDog?
Report
Congrats on the launch! The "without changing your app" part is the real pitch here. I run a Java/Spring stack on Postgres 17 and an embarrassing share of my production incidents trace back to connection handling — pool exhaustion during traffic spikes, session state breaking when something in the middle does transaction-level pooling, that kind of thing. Two questions: does PgDog do transaction-mode pooling à la PgBouncer, and if so how do you handle prepared statements / session state? And is the sharding routing done by parsing the query itself, or do I hint it? Genuinely curious — this layer is where I've been burned the most.
Report
finally a pgpooler alternative that actually feels modern, set it up behind our staging cluster last week and the latency under load was noticeably more stable than pgbouncer. love that it speaks the postgres protocol too
The no app changes part is the bit I'd evaluate first — especially pooling + prepared statements under load. Not sure if I missed it, but is there a recommended migration path for teams already using PgBouncer?
2M qps in production is the number that actually matters here. schema migrations on a sharded setup - does PgDog coordinate an ALTER TABLE across all shards atomically, or is sequencing that still on the DBA?
PgDog
Yup, using two-phase commit.
Congrats on the launch. One thing that would help teams adopt this faster is a built-in dashboard or web UI for live monitoring of pool stats, query latency, and shard distribution. Most teams using pgBouncer end up bolting on tools like pgwatch2 or custom Grafana setups, so having something more turnkey would be a real differentiator.
PgDog
That's included in the enterprise edition: https://docs.pgdog.dev/enterprise_edition/control_plane/#installation
2M qps in production is a real number, not a launch-day claim. the part I'd actually worry about with transparent sharding is cross-shard joins and multi-shard transactions, since that's usually where these proxies either quietly fall back to something expensive or just reject the query outright. does pgdog handle that at the protocol level too, or is there a class of queries you tell people to just not run against a sharded setup
Lev — 2M qps across production deployments for over a year is a real data point, not a launch-day claim (as Gal put it below). WinBidIQ's Postgres load is basically bimodal: a nightly batch job writes tens of thousands of updated federal opportunity rows scraped daily, then daytime traffic is almost all reads — scoring, dashboard, search — from SaaS users. Right now we just add read replicas and hope the app connects to the right one. Does PgDog handle read/write splitting itself, routing reads to replicas automatically, or is that still a decision the app has to make before the query ever reaches PgDog?
Congrats on the launch! The "without changing your app" part is the real pitch here. I run a Java/Spring stack on Postgres 17 and an embarrassing share of my production incidents trace back to connection handling — pool exhaustion during traffic spikes, session state breaking when something in the middle does transaction-level pooling, that kind of thing. Two questions: does PgDog do transaction-mode pooling à la PgBouncer, and if so how do you handle prepared statements / session state? And is the sharding routing done by parsing the query itself, or do I hint it? Genuinely curious — this layer is where I've been burned the most.
finally a pgpooler alternative that actually feels modern, set it up behind our staging cluster last week and the latency under load was noticeably more stable than pgbouncer. love that it speaks the postgres protocol too
PgDog
Super cool, glad it works for you!
The no app changes part is the bit I'd evaluate first — especially pooling + prepared statements under load. Not sure if I missed it, but is there a recommended migration path for teams already using PgBouncer?