PgDog

Scale PostgreSQL without changing your app

Open Source

Developer Tools

Database

Visit WebsiteSee on Product HuntTwitter ⧉Github ⧉

The "scale Postgres without changing your app" framing is the part that matters for teams that can't stop to re-architect — connection pooling plus transparent routing means the app stays naive. My one question as I'd drop this in front of an existing service: how does PgDog handle a single transaction that touches rows on multiple shards — does it coordinate the cross-shard write, or is keeping a transaction inside one shard still the app's job? Curious where the sharding proxy's transparency stops.

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?

the config-driven instances not talking to each other is a clean HA story, but during a shard rebalance does every instance get the new shard map atomically, or is there a window where two instances disagree on where a shard actually lives?

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?

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! 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'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?

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.

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

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

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?