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.
We've been working on PgDog for over a year. It's running in production, serving over 2M queries per second across dozens of deployments. Sharding is working, too! Building PgDog in the open has been really great: our users and customers contribute features and bug fixes, every day. Give it a try and let us know what you think!
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
How do you plan to handle failover and redundancy in PgDog, especially in cases where the load balancer or connection pooler itself becomes a single point of failure?
We run multiple instances. They are config-driven, so they don't talk to each other. HA by design.
Report
I appreciate the honesty in positioning this as scaling without forcing app changes. Usually, "seamless scaling" secretly means rewriting half your queries to fit a proprietary router, so tackling this transparently at the protocol level makes a ton of sense.
Wondering what the tradeoff on latency looks like under the hood, when it's intercepting traffic on the fly, is there a noticeable overhead for high frequency, simple reads compared to just hitting standard postgres?
Very little overhead. If you're running a connection pooler already (e.g., pgbouncer), you won't notice much of a difference.
Report
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
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's connection pooling and transparent query routing is technically elegant. It removes the need to re-architect your data layer, which saves weeks of migration work. We've hit connection saturation issues under bursty SaaS workloads and this seems like a real fix. How does PgDog handle long-running transactions during a shard rebalance or failover?
If the transaction is taking too long, we break it. Failovers are immediate, so we break the transaction and bubble up the error to the client.
Report
Congrats on the launch! Running a SaaS on Neon's serverless Postgres — connection pooling is one of those things you don't think about until it bites you in production. Couple of questions: how does PgDog handle the connection limit quirks of serverless Postgres vs traditional dedicated instances? And is there a recommended setup for a Next.js + Prisma stack?
PgDog works with all Postgres databases, incl. the serverless kind. It'll try to minimize the number of connections it needs in both, so you should see quite a bit of an improvement if you deploy it in front of Neon, for example.
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?
Replies
PgDog
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!
How do you plan to handle failover and redundancy in PgDog, especially in cases where the load balancer or connection pooler itself becomes a single point of failure?
PgDog
We run multiple instances. They are config-driven, so they don't talk to each other. HA by design.
I appreciate the honesty in positioning this as scaling without forcing app changes. Usually, "seamless scaling" secretly means rewriting half your queries to fit a proprietary router, so tackling this transparently at the protocol level makes a ton of sense.
Wondering what the tradeoff on latency looks like under the hood, when it's intercepting traffic on the fly, is there a noticeable overhead for high frequency, simple reads compared to just hitting standard postgres?
PgDog
Very little overhead. If you're running a connection pooler already (e.g., pgbouncer), you won't notice much of a difference.
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
ExploreYC
PgDog
thanks! we try
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
PgDog's connection pooling and transparent query routing is technically elegant. It removes the need to re-architect your data layer, which saves weeks of migration work. We've hit connection saturation issues under bursty SaaS workloads and this seems like a real fix. How does PgDog handle long-running transactions during a shard rebalance or failover?
PgDog
If the transaction is taking too long, we break it. Failovers are immediate, so we break the transaction and bubble up the error to the client.
Congrats on the launch! Running a SaaS on Neon's serverless Postgres — connection pooling is one of those things you don't think about until it bites you in production. Couple of questions: how does PgDog handle the connection limit quirks of serverless Postgres vs traditional dedicated instances? And is there a recommended setup for a Next.js + Prisma stack?
PgDog
PgDog works with all Postgres databases, incl. the serverless kind. It'll try to minimize the number of connections it needs in both, so you should see quite a bit of an improvement if you deploy it in front of Neon, for example.
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?