PgDog

PgDog is a PostgreSQL connection pooler, load balancer, and database sharder designed to help scale databases without application changes. It multiplexes thousands of application connections over fewer PostgreSQL server connections and supports SET, LISTEN/NOTIFY, and advisory locks. Read queries can be distributed across replicas, while writes are routed to the primary; health checks and failover detection are included. Sharding keys guide query routing, and queries without a key can run across databases in parallel. Cross-shard transactions use PostgreSQL prepared transactions and two-phase commit, with automatic rollback on errors. PgDog can copy data and stream row changes to another database while query traffic continues. Deployment options include Kubernetes Helm, Docker, AWS ECS Terraform, pre-built binaries, and source. Releases include Linux arm64 and amd64, Apple Silicon Mac, and Debian packages; the macOS binary is unsigned. The project is free and open source under AGPL-3.0. Its documentation says internal use does not require sharing source code. Enterprise support includes a dedicated Slack channel, architecture reviews, and an SLA promising a response within 15 minutes.

PgDog brings pooling, routing, and sharding capabilities together for PostgreSQL deployments. Teams should account for the unsigned macOS binary and distinguish the free open-source project from enterprise support.

PgDog suits teams running PostgreSQL that want connection pooling, read balancing, or sharding without changing their application. It also offers enterprise support for organizations needing a dedicated channel and a response SLA.

PgDog is a PostgreSQL proxy that combines connection pooling, replica-aware routing, and database sharding behind an application-compatible layer. It suits teams operating PostgreSQL at scale that want to add capacity without rewriting application code. The strongest case is a self-managed deployment needing several scaling mechanisms in one open-source project; teams wanting a narrower pooler or a managed service should look elsewhere.

Overview

PgDog sits between applications and PostgreSQL servers. It multiplexes large numbers of client connections onto fewer database connections, balances reads across replicas, sends writes to the primary, and can distribute data across shards. That breadth makes it more capable than a pooler alone, but also makes it an infrastructure component for teams comfortable running PostgreSQL operations themselves.

The project is free and open source under AGPL-3.0. Its documentation says internal use does not require sharing source code, a useful distinction for companies deploying it inside their own organization. PgDog is focused exclusively on PostgreSQL, so it is not a fit for a mixed-database proxy strategy.

For a wider category comparison, see Database Proxy Software.

Key features

Pooling and routing

PgDog can multiplex thousands of application connections over a smaller set of PostgreSQL server connections. Support for SET, LISTEN/NOTIFY, and advisory locks means applications that depend on these session behaviors are not limited to the simplest pooling patterns. This is most valuable when connection counts are stressing database resources without corresponding query volume.

Read queries are distributed across replicas while writes go to the primary. Health checks and failover detection give the router information to redirect traffic when database availability changes, making it a practical option for replicated PostgreSQL installations rather than a passive connection broker.

Sharding, transactions, and resharding

Queries with a sharding key can be directed to the relevant database. Queries without a key can execute across databases in parallel, which broadens what can run after data is partitioned but can also create more distributed work than a targeted query. Cross-shard transactions use PostgreSQL prepared transactions and two-phase commit, with automatic rollback on errors. That addresses consistency across shards, although teams still need to design for the coordination cost of distributed transactions.

PgDog can copy data and stream row changes to another database while query traffic continues. Online movement is useful when changing shard placement without scheduling a full outage.

Operations and security

Deployment options include Kubernetes Helm, Docker, AWS ECS Terraform, pre-built binaries, and source builds. Prometheus and OTEL exporters, along with Incident.io alert integration, are described for the enterprise offering. Enterprise control-plane documentation also describes SSO, while supported environments such as Kubernetes or AWS Secrets Manager can encrypt user credentials at rest.

Pricing

The open-source plan is the clear choice for teams willing to deploy and support the software themselves. It gives up the production control plane, insights, dedicated Slack channel, and SLA-backed response promise associated with Enterprise. Enterprise support includes a response within 15 minutes, architecture reviews, and a dedicated Slack channel, which matters when PgDog is part of a business-critical database path.

Platforms

PgDog supports Linux, macOS, Windows, and self-hosted deployment. Pre-built releases cover Linux arm64 and amd64, Apple Silicon Mac, and Debian packages. The macOS binary is unsigned, so Mac administrators should expect an additional trust or installation step. Kubernetes, Docker, AWS ECS Terraform, binary, and source deployment choices suit organizations with varied infrastructure standards.

Who it's for

PgDog is aimed at PostgreSQL teams that need to reduce connection pressure, route around replicas and failover events, or introduce sharding without application changes. It is especially suitable when online data movement and cross-shard transaction handling justify adopting a broader proxy layer. It is less suitable for teams that only need a minimal pooler, do not want AGPL-3.0 software in their architecture, or prefer a managed control plane from the outset.

Pros and cons

Pros

• One PostgreSQL layer for pooling, routing, and sharding: avoids assembling separate components for these jobs.
• Application-compatible scaling: connection multiplexing and query routing are designed to work without application changes.
• Distributed-workload coverage: parallel keyless queries, two-phase-commit transactions, and online row streaming address difficult sharded-database operations.
• Flexible deployment: self-hosted teams can choose containers, Kubernetes, cloud infrastructure, binaries, or source.

Cons

• PostgreSQL-only scope: it does not serve teams seeking one proxy for multiple database engines.
• Operational responsibility on the free plan: control-plane features and SLA-backed support are reserved for Enterprise.
• AGPL-3.0 licensing: organizations with restrictive licensing policies need legal review before adoption.
• Unsigned macOS binary: Mac deployments require extra attention during installation.

Alternatives

PgBouncer is the simpler free, self-hosted choice when connection pooling is the primary requirement and sharding or replica routing is unnecessary.

PgCat is another free, self-hosted PostgreSQL-oriented option for teams comparing open-source poolers.

MySQL fits teams that need a freemium database platform spanning SQL and NoSQL applications, replication, and high availability rather than a PostgreSQL-only proxy.

ProxySQL is the alternative for Linux and self-hosted deployments centered on MySQL-compatible database proxying.

SPQR is a free, open-source PostgreSQL sharding option when sharding is the specific priority.

TurbineProxy offers a free Apache-2.0 proxy with no per-query fees.

Amazon RDS is the better direction for teams seeking a managed AWS database service with a free-tier entry point.

DBLE is a free GPL-2.0 open-source alternative with enterprise support plans.

Verdict

Choose PgDog if you run PostgreSQL yourself and want pooling, read/write routing, failover-aware behavior, and sharding in one application-transparent layer. Its free open-source plan and online resharding capabilities are compelling for capable infrastructure teams. Look elsewhere if you need a minimal pooler, a non-PostgreSQL solution, or managed operations and licensing terms that do not require AGPL review.