PgDog Review (2026): Pricing, Features & Honest Verdict

PgDog is an open-source PostgreSQL proxy that scales your database without touching your app code. It’s a single Rust executable that pools connections, load-balances reads, and shards Postgres across many machines. It’s best for engineering teams pushing a single Postgres primary past its limits. It’s free and open source. Rating: 8/10.

What Is PgDog?

PgDog is a database proxy that sits between your application and PostgreSQL. From your app’s point of view, it looks and behaves exactly like a normal Postgres server. You point your connection string at PgDog instead of at your database, and it handles the messy parts underneath: managing connections, spreading reads across replicas, and, when you need it, splitting your data across multiple database servers. The whole thing ships as one executable written in Rust, so there’s no sprawling stack of sidecars to babysit. The tagline says it plainly: scale PostgreSQL without changing your app.

The pedigree here is hard to ignore. PgDog was founded by Lev Kokotov, who previously built PostgresML and led storage infrastructure at Instacart, where he scaled databases past 100TB. The company went through Y Combinator’s Spring 2025 batch and raised a $5.5M seed round, and it’s run by a small team of around three people. That funding and focus show up in who’s already using it. Coinbase, Ramp, Modal, and Span are named users, and PgDog has been run against 20TB+ sharded databases, 2M+ queries per second, and connection pools serving more than 100,000 clients. Those are serious numbers for a project this young.

What Are PgDog’s Key Features?

Connection Pooler

Postgres doesn’t love having tens of thousands of clients connected at once. Each connection costs memory and backend processes, and past a certain point the database spends more time managing connections than answering queries. PgDog’s pooler solves this by keeping a small number of real Postgres connections open and multiplexing your huge client population across them. It can sit in front of 100,000+ clients while the database only ever sees a handful of active connections. And it does this without breaking database features you actually rely on, which is where a lot of naive poolers fall down.

Load Balancer

If you run read replicas, you want your read traffic spread across them instead of hammering the primary. PgDog distributes reads across your replicas automatically, so you get more read throughput without wiring routing logic into your application. It also watches for replication lag and handles failovers on its own. If a replica falls behind or drops out, PgDog notices and routes around it, which means a lagging replica doesn’t quietly start serving stale data to your users. That kind of awareness is the difference between a load balancer that helps and one that causes a 3am page.

Distributed Database and Sharding

This is the feature that sets PgDog apart from the pack. It can shard a single logical Postgres database across many physical servers, with automatic query routing so your app doesn’t need to know which shard holds which row. For analytical queries that need to touch everything, it does scatter/gather, running the query across all shards and combining the results. Data distribution is configuration-driven and compatible with standard Postgres types, so you’re not forced into some exotic schema to make it work. You get horizontal scale while your application keeps speaking plain Postgres.

ACID at Scale

Sharding usually forces an ugly trade-off: the moment your data lives on multiple machines, transactions get hard and consistency gets fuzzy. PgDog leans on native Postgres two-phase commit to keep things honest. A cross-shard transaction writes to all the shards atomically, so either every shard commits or none of them do. If anything goes wrong along the way, PgDog triggers an automatic rollback across the board. You keep real ACID guarantees even when your database is spread across a dozen servers, which is exactly the property most sharding setups quietly give up.

How Much Does PgDog Cost?

Everything PgDog builds today is open source and free. The code lives on GitHub, where it’s collected around 5,000 stars, and you can download it, run it, and shard your entire production fleet without paying anyone a cent. There’s no per-connection fee, no seat pricing, and no license gate on the core features. If you’re comfortable operating your own infrastructure, the sticker price is zero.

There is an enterprise tier in the picture, but the pricing isn’t public. The company is still early and working through a design-partner phase, so support and enterprise arrangements are custom conversations rather than a published price sheet. If you need a contract, an SLA, or hands-on help running PgDog at scale, you’ll be talking to the team directly rather than picking a plan off a page. I’d expect that to firm up as the company matures, but right now there are no public enterprise numbers, and you shouldn’t trust any figure that claims otherwise.

For context, this is roughly how the open-source Postgres tooling world prices itself. PgBouncer and PgCat are both free and open source with no commercial tier attached. Citus is open source too, with paid pricing showing up only through the managed Azure Cosmos DB for PostgreSQL offering. So PgDog charging nothing for the software and reserving money for enterprise support is a familiar model, not an outlier.

Who Is PgDog Best For?

Use PgDog if you’re running high-traffic Postgres and you can feel the ceiling of a single primary getting close. If your connection counts are exploding, your read replicas need smarter routing, or you’re staring down a sharding project you really don’t want to hand-roll, this is aimed squarely at you. It’s a strong fit for startups scaling fast that refuse to rewrite their application or abandon Postgres just to get more headroom. The pitch is that you keep your app, keep your database engine, and add PgDog in front to buy yourself a lot of runway.

Skip PgDog if a single Postgres instance already handles your load comfortably, or if a primary plus a couple of read replicas is plenty. Adding a proxy and, worse, a sharded topology, is real operational weight you shouldn’t take on before you need it. And skip it for now if what you want is a fully managed, hosted service with SLAs you can buy today. PgDog is something you self-host and operate yourself, and there’s no push-button managed cloud offering yet. If your team has no appetite for running infrastructure, that gap matters.

What Are the Best PgDog Alternatives?

PgBouncer is the battle-tested default for connection pooling in the Postgres world. It’s free, open source, and has been quietly holding production systems together for years. But pooling is all it does. There’s no load balancing across replicas and no sharding, so if connections are your only problem it’s a fantastic, boring choice, and if you need more than that you’ll outgrow it.

PgCat is closer to PgDog in spirit. It’s an open-source, Rust-based pooler with load balancing built in, and it also came out of the Postgres community. It’s free and a solid step up from PgBouncer if you want read distribution alongside pooling. Its sharding story is lighter than PgDog’s, though, so if distributed writes and cross-shard transactions are the goal, PgDog is the more ambitious tool.

Citus takes a different route. Instead of a proxy, it’s a Postgres extension that turns your database into a distributed, sharded system. It’s open source, with a managed option available through Azure. If you’re comfortable running an extension inside Postgres rather than a proxy in front of it, Citus is the mature, well-known name in Postgres sharding. Worth a look if you want a distributed SQL approach with a hosted path already available. For readers coming from the MySQL side, Vitess is the rough equivalent there, and it’s a useful mental model for what PgDog is reaching toward on Postgres.

Final Verdict: Is PgDog Worth It?

PgDog is tackling one of the hardest problems in databases, and it’s doing it with the right people and real money behind it. Pooling, load balancing, and sharding in a single Rust binary, with cross-shard ACID transactions built on Postgres two-phase commit, is an ambitious combination. The fact that companies like Coinbase and Ramp are already running it, at 20TB+ and 2M+ queries per second, tells you the core actually works under pressure. For a project this young, that track record is impressive and it’s the main reason the rating lands as high as it does.

The caution is all about maturity, not capability. This is a small team in an early design-partner phase, enterprise pricing is unknown, there’s no managed cloud yet, and sharding will always add operational complexity to your stack no matter how clean the tooling is. You’re also stepping into a space with entrenched, trusted incumbents. But if you’re hitting the wall on a single Postgres primary and you want to scale out without rewriting your app or leaving Postgres behind, PgDog is one of the most exciting options out there right now. I’d rate it 8 out of 10: adopt it if you have the operational muscle to self-host, keep a close eye on it if you’re waiting for a managed offering, and either way it’s a project worth betting on.