PgDog Is Betting That Postgres Sharding Doesn't Have to Hurt

The Macro: Postgres Won the Database Wars. Scaling It Is Still a Mess.

PostgreSQL won. That debate is over. It’s the default database for startups, the preferred choice for enterprises migrating off Oracle, and the engine behind most of the software you use every day. Stack Overflow surveys, DB-Engines rankings, job postings, all of them point in the same direction. Postgres is the relational database of the 2020s.

But winning the popularity contest and being easy to scale horizontally are two very different things. Postgres was designed as a single-node database. It’s phenomenal at that. When your data outgrows one server, or your read traffic exceeds what a single primary and a few replicas can handle, things get uncomfortable fast.

The options today are not great. You can use Citus, which bolts sharding onto Postgres but comes with its own limitations and recently got absorbed into Microsoft’s Azure ecosystem. You can jump to CockroachDB or YugabyteDB, which are Postgres-compatible but not actually Postgres. Or you can manually partition your data across multiple Postgres instances and manage routing in your application code, which is roughly as fun as it sounds.

Connection pooling is its own separate headache. PgBouncer has been the standard for years, and it works, but it’s single-threaded and limited in what it understands about your queries. AWS RDS Proxy exists but adds latency and cost. Neither of these tools help with sharding. They just help your existing database accept more connections without falling over.

The market for database infrastructure tools is substantial and growing. Postgres-specific tooling is a real category now, not just a niche. Companies are spending serious money on database scaling because the alternative is spending serious engineering time. That tradeoff only goes one direction as salaries keep climbing.

The Micro: One Binary, Three Problems Solved

PgDog is a PostgreSQL proxy that handles connection pooling, load balancing, and sharding in a single binary. It sits between your application and your database, intercepts SQL queries, and routes them to the right place. Your application code doesn’t change. Your schema doesn’t change. You deploy PgDog, point your app at it instead of directly at Postgres, and it handles the rest.

Lev Kokotov built this. He’s the founder and, at the time of the Y Combinator Spring 2025 batch, the sole team member. His background is directly relevant here. He was at Instacart in 2020 when the pandemic sent grocery delivery demand through the roof, and he was the engineer who sharded their Postgres infrastructure to handle that growth. After Instacart, he built PostgresML. The man has a type.

The connection pooling piece is multi-threaded, which already puts it ahead of PgBouncer for high-throughput workloads. The load balancer understands SQL well enough to separate reads from writes and route them to the correct replicas or the primary. That’s useful because most applications are read-heavy, and spreading reads across replicas is one of the cheapest ways to scale.

The sharding is where things get interesting. PgDog can distribute data across multiple Postgres instances based on a sharding key, and it handles cross-shard queries including aggregates, sorting, and multi-tuple inserts. That last part matters. A lot of sharding solutions punt on cross-shard operations and tell you to restructure your queries. PgDog is trying to handle them transparently.

It also includes automatic failover. If a replica goes down or falls behind on replication, PgDog detects it and reroutes traffic. Logical replication support means you can add shards without downtime. The monitoring layer provides real-time metrics and query analysis.

The customer list on the website includes names like Coinbase, Ramp, and Modal. For a single-person company out of YC, that’s a strong signal. These are companies that run Postgres at scale and have the engineering talent to evaluate alternatives thoroughly.

The open-source angle is important. PgDog’s core is on GitHub, which means you can inspect the code, contribute to it, and run it yourself without paying anyone. The business model will presumably involve hosted or enterprise versions with additional features, but the base product is available for free.

The Verdict

PgDog is solving a real problem that I’ve watched teams struggle with for years. Postgres scaling is one of those things where the existing options all come with significant compromises, and the gap between “this works for our current scale” and “we need something better” tends to show up at the worst possible time.

The single-founder risk is real. This is a complex piece of infrastructure that sits in the critical path of every database query. Companies evaluating PgDog for production use will want to know that the project has enough momentum and funding to survive if Lev gets hit by a bus. The YC backing helps, and the open-source model means the code isn’t going to disappear, but a one-person infrastructure company is a hard sell for risk-averse engineering managers.

What I like is the clarity of the pitch. PgDog replaces PgBouncer, replaces RDS Proxy, replaces your custom sharding code, and replaces your manual failover scripts. One tool instead of four. If it actually delivers on that, the value proposition is obvious.

At 90 days, I’d want to know two things. First, how does cross-shard query performance compare to manual sharding with application-level routing? Transparent sharding is convenient, but if it’s significantly slower, teams will just write the routing code themselves. Second, what does the upgrade path look like when PgDog itself needs to be updated? Upgrading a proxy that sits in front of every database query is a high-stakes operation, and how gracefully the project handles that will say a lot about its production readiness.

Lev clearly knows this problem space. The Instacart pedigree is not decoration. If PgDog delivers on half of what the feature list promises, it fills a gap that Postgres users have been working around for years.