PgDog - Horizontal scaling for PostgreSQL
Announcing our $5M seed funding<br>Read the post→
-->
Scale Postgres n times
Connection pooler, load balancer, distributed database. One executable, deployable anywhere.
Install PgDog<br>Talk to us<br>Read the docs
v0.4latest
4.3kgithub stars
Apache-2license
Rustwritten in
-->
your app<br>asyncpg · pgx<br>libpq · ruby-pg
pgdog
pooler
load balancer
dsql
pg·shard 0<br>primary + 2r
pg·shard 1<br>primary + 2r
pg·shard 2<br>primary + 2r
helm<br>docker
copy<br>1helm repo add pgdogdev https://helm.pgdog.dev
2helm install pgdog pgdogdev/pgdog
copy<br>1docker run ghcr.io/pgdogdev/pgdog:latest
10 TB+ sharded<br>1 M+ queries/s in production
Throughput calculator<br>pgdog v0.4 · single cluster
Postgres instance
db.r6g.large (2 vCPU, 16 GB)<br>db.r6g.xlarge (4 vCPU, 32 GB)<br>db.r6g.2xlarge (8 vCPU, 64 GB)<br>db.r6g.4xlarge (16 vCPU, 128 GB)
Workload
OLTP (90% reads / 10% writes)<br>Write-heavy (50/50)<br>Fan-out reads (cross-shard)
Shards<br>4primaries
Replicas per shard<br>2read replicas
Client connections<br>5,000open sockets
Dataset size<br>1.2 TBtotal
Sustained throughput
p99
48,000 tx/s
Latency<br>4 shards · 1 kB rows
Routed read<br>Sharded write<br>Cross-shard join
workload<br>10k tx/s · 4 shards · rc isolation
p50
0.9 ms / 4.1
p90
1.8 ms / 9.2
p99
4.6 ms / 21.0
p99.9
9.2 ms / 48.0
via pgdog<br>pgbouncer + manual sharding
Method · 32 clients, 10 min steady state<br>⎇ pgdog/bench
-->
// Drop-in PostgreSQL proxy,<br>// no app changes required.
Three tools in one.
01 · Connection pooler
Real transaction mode
PgDog can share just a few Postgres connections between 100,000+ clients, without breaking Postgres features.
✓Session state : SET commands, advisory locks and LISTEN/NOTIFY; no connection pinning.
✓Multi-threaded and async : 50,000+ transactions/s per thread, without query length or connection limits.
✓Prepared statements : compatible with all client drivers, with zero overhead.
config<br>diagram
1# pgdog.toml
2[general]
3default_pool_size = 100
5[[databases]]
6name = "prod"
7host = "10.0.0.1"
clients
app · 1
app · 2
app · 3
… 100k
pgdog
conn 0
conn 1
conn 2
pg · 5432<br>primary
02 · Load balancer
ALB for your database
PgDog can distribute reads between replicas, detect replication lag, hardware failure, and primary failovers. Use just one endpoint for all your queries.
✓Health checks : block out-of-date or broken replicas from serving queries.
✓Failover detection : move write traffic to the new primary, without config changes.
✓Read / write split : route SELECT queries to the replicas, all others to the primary. Uses the internal Postgres SQL parser for maximum compatibility.
config<br>diagram
1# pgdog.toml
2[[databases]]
3name = "prod"
4host = "10.0.0.1"
5role = "primary"
7[[databases]]
8name = "prod"
9host = "10.0.0.2"
10role = "replica"
11
12[[databases]]
13name = "prod"
14host = "10.0.0.3"
15role = "replica"
app
pgdog
sql parser
r/w split
health checks
failover
pg·primary<br>writes
pg·replica 1<br>reads
pg·replica 2<br>reads
03 · Distributed database
Shard Postgres, without app changes
PgDog gets the sharding key directly from queries and sends them to the right shard. Queries without one are executed across all databases, in parallel.
✓Fast OLTP : use sharded databases just like plain old Postgres, with a horizontally scalable coordinator.
✓Fast OLAP : GROUP BY, COUNT(), AVG(), ORDER BY, MIN(), MAX(), COPY and many more ops supported out of the box. Postgres + PgDog = scatter/gather engine.
✓Shard by anything : flexible, configuration-driven data distribution, compatible with standard Postgres data types.
config<br>diagram
1# pgdog.toml
2[[databases]]
3name = "prod"
4host = "10.0.0.1"
5shard = 0
7[[databases]]
8name = "prod"
9host = "10.0.0.2"
10shard = 1
11
12[[sharded_tables]]
13database = "prod"
14column = "tenant_id"
app
pgdog
sql parser
coordinator
scatter/gather
OLTP/OLAP
pg·shard 0<br>tenants 0–33%
pg·shard 1<br>tenants 34–66%
pg·shard 2<br>tenants 67–100%
Distributed, consistent, relational
PgDog doesn't trade speed for consistency. It maintains ACID compliance, at scale.
✓Cross-shard transactions : write data to all shards, atomically. Any error triggers an automatic rollback, using native Postgres prepared transactions and two-phase commit.
✓Replicated tables : not all tables need to be sharded. Store the same data on all shards and use it for fast, shard-local joins.
✓Integer primary keys : no need to switch to UUIDs. PgDog supports monotonic, big integer primary keys, generated automatically in the proxy.
✓Sharding key mutation : move rows between shards using only UPDATE statements.
✓Consistent schema : DDL is automatically cross-shard. Migration tools like Alembic, ActiveRecord migrations and others work out of the box.
1-- Cross-shard transactions,
2-- with big integer primary keys.
3BEGIN;
5INSERT INTO users (email, ip_addr, created_at)
6VALUES ($1, $2, now()), ($3, $4, now())
7RETURNING id;
9COMMIT;
10
11--...