PgDog gets funded: sharded Postgres without the Citus tax

What happened

PgDog announced seed funding for its open-source Postgres sharding proxy. The company, founded by Lev Kokotov — previously the author of PgCat, the connection pooler that replaced PgBouncer at Instacart and several other large Postgres shops — is pitching a deceptively simple product: a transparent proxy that sits in front of N vanilla Postgres instances and shards your traffic across them based on a configurable sharding key.

The differentiator is what PgDog is *not* doing: it is not a fork of Postgres, not a custom storage engine, and not a managed-only service. Each shard is a stock `postgres` binary you could install with `apt`. PgDog handles the routing, the cross-shard query rewriting it can do, the rebalancing, and the connection pooling. Everything else is your existing Postgres knowledge, your existing extensions, your existing backup tooling.

The project is written in Rust, picks up where PgCat left off architecturally, and the funding round (per the announcement) is positioned as runway to build out the commercial control plane while keeping the core open source. No customer logos were disclosed in the post, but Kokotov's track record at Instacart — where Postgres ran across petabytes and the in-house pooler became a load-bearing piece of infrastructure — is the implicit pitch.

Why it matters

The Postgres sharding landscape has been weirdly stuck for a decade. Citus, the most popular answer, requires you to declare distributed tables, learn its DDL extensions, and accept that you're now running a Citus-flavored Postgres rather than the real thing. Microsoft acquired Citus in 2019, folded it into Azure, and the open-source story has been quietly de-prioritized ever since. Vitess for Postgres has been promised for years and remains MySQL-first in practice. CockroachDB and Yugabyte are wire-compatible but the storage layer is entirely different — your `EXPLAIN` plans, your extension ecosystem, your operational muscle memory all get thrown out.

PgDog's bet is that most teams don't want any of that. They want their existing schema, their existing `pg_stat_statements` workflows, their existing `pgBackRest` jobs, their existing `pg_dump` muscle memory — just with a sharding key plumbed through. The proxy model has obvious precedents: ProxySQL for MySQL, Twemproxy for memcached, Envoy for everything. The novel claim is that 80% of the sharding problem is just routing queries to the right shard, and the remaining 20% — cross-shard joins, distributed transactions, global secondary indexes — is best left exposed rather than papered over with a leaky abstraction.

The community reaction on Hacker News was characteristically split. Postgres operators who've been bitten by Citus's quirks (the partition-column-must-be-everywhere requirement, the distributed deadlock detector, the upgrade pain) are enthusiastic. Skeptics point out the obvious gap: if your workload genuinely needs cross-shard joins on hot paths, no proxy is going to save you, and you're back to either rearchitecting or moving to a real distributed database. That criticism is fair, and Kokotov hasn't pretended otherwise — PgDog's docs are upfront that joins crossing shard boundaries are either rewritten as scatter-gather or rejected at parse time.

The more interesting comparison is to ReadySet and PolyScale at the caching layer, and to Neon's branching architecture at the storage layer. None of those are sharding solutions, but they're all attacking the same underlying problem: Postgres's single-primary write path doesn't scale linearly, and the industry has invented a half-dozen workarounds rather than fixing it at the engine level. PgDog is the workaround that asks the least of you upfront and the most of you when joins get complicated.

What this means for your stack

If you're running Postgres under 500GB on a single primary, PgDog is irrelevant — buy a bigger box. The interesting threshold is roughly 2TB and above, or any write workload where you're seeing WAL throughput bottlenecks during peak traffic. Below that, the operational cost of running N shards plus a proxy plus the cross-shard query gymnastics is almost certainly worse than vertical scaling.

Above that threshold, the practical question is: can you identify a clean sharding key in your existing schema without rewriting application code? For multi-tenant SaaS, `tenant_id` is usually obvious. For consumer products, `user_id` works if you've been disciplined. For analytical workloads with lots of joins across dimension tables, the answer is often "no" and you should be looking at ClickHouse or DuckDB-backed lakehouses instead of sharding OLTP Postgres at all.

If you do have a clean key, the migration path is genuinely incremental — you can run PgDog in front of a single shard, validate the routing, then add shards and rebalance. That's a meaningfully different risk profile than a Citus migration, which is a one-way door requiring schema changes. The escape hatch is real: if PgDog doesn't work out, your shards are still stock Postgres and you can dump-restore back to a single primary or migrate to anything else that speaks the wire protocol.

Looking ahead

The quiet story here is that Postgres's center of gravity is shifting from "the database" to "the protocol and ecosystem." Neon, Supabase, PgDog, ParadeDB, pg_duckdb — the interesting bets in 2026 are all building *around* vanilla Postgres rather than forking it. That's a healthier trajectory than the database-fork era of the mid-2010s, and PgDog's funding suggests at least one investor thinks the proxy-shaped hole in that landscape is large enough to support a company. Whether it's large enough to support a venture-scale company is the open question — but for practitioners staring down a single-primary wall, the relevant news isn't the round size. It's that there's now a credibly-funded team whose job is to make sharded Postgres feel like Postgres.