PgDog

1. You primarily need advanced analytics and complex cross-shard aggregates

   • PgDog documents basic cross-shard aggregate support; in-database systems such as Citus may provide more mature distributed query features.

2. You require a turnkey distributed SQL database with published vendor SLAs and compliance attestations

   • Vendors offering managed distributed SQL systems may provide clearer enterprise contracts, SLAs, and compliance artifacts.

3. You cannot absorb the operational complexity of sharding

   • Sharding increases operational overhead (schema coordination, tenant migration, resharding runbooks). PgDog can reduce certain application changes but does not eliminate distributed-systems operational complexity.

4. AGPL licensing is unacceptable for your organization

   • Some organizations bar AGPL components or require additional legal review before adoption.

• Uses the Postgres parser (via pg_query) to interpret SQL, with the goal of maintaining high SQL compatibility for routing decisions.
• Provides a single executable that integrates pooling, load balancing, and sharding control.
• Designed to operate outside of Postgres, enabling use with managed Postgres services without installing extensions.
• Includes operational features such as health checks, failover routing, an admin database, and OpenMetrics-compatible metrics.

Because there were no clear G2/Capterra reviews, community and launch discussions provide much of the public feedback, which can be more informal and variable in quality.

Hacker News (technical commentary):

“PgDog’s architecture is fundamentally different. It runs outside the DB… you can deploy it anywhere, including managed Postgres like RDS…”

Reddit (skeptical about project longevity and ecosystem churn):

“(Rewriting in Rust) is getting annoying. Especially given you know it end up getting abandoned.”

Reddit (cautious, noting active development):

“Nice to see. Just checked and the dev is working on this this week, so not abandoned ware!”

The vendor blog contains narrative posts describing sharding experiences and performance testing. These posts provide implementation details and the vendor's perspective but are not independent third-party case studies.

Example: performance claims in a vendor blog post

• The vendor reports high data-movement and write-throughput figures based on vendor-conducted tests. These figures are dependent on workload, network, and infrastructure configuration; they should be validated against an organization's own environment before relying on them for capacity planning.

Example: pooling and performance comparison

• A blog post presents pgbench raw TPS numbers and configuration details comparing PgDog with PgBouncer in a specific setup. The post provides configuration and raw data, which improves transparency relative to a purely descriptive claim; however, the results are vendor-run and may not generalize across different hardware, kernel/TLS configurations, or production query mixes.

Critical evaluation summary: vendor-run tests offer useful data points and configuration details for replication, but buyers should plan independent benchmarking that reflects their production workload.

PgDog is a PostgreSQL-aware proxy that combines connection pooling, read/write splitting with replica load balancing, and query routing for sharded PostgreSQL deployments. It runs outside Postgres (not an in-database extension), speaks the Postgres wire protocol, parses SQL using the native Postgres parser (via pg_query), and routes traffic to primaries/replicas and/or multiple shards. It also provides operational features such as health checks, failover routing, and metrics exposure.

In practical terms, PgDog is intended to allow teams to:

• keep standard Postgres deployments (including managed Postgres like RDS / Cloud SQL)
• scale connection concurrency via pooling
• scale read throughput via replica load balancing
• scale data volume and write throughput by splitting tenants or rows across multiple Postgres databases (sharding)

Vendor messaging promotes horizontal scaling of Postgres and reduced application code changes; however, sharding solutions typically still require careful schema design and query-pattern alignment (see "Known Issues & Limitations").