The post is a funding announcement for PgDog, a Rust proxy that sits in front of PostgreSQL and handles connection pooling, read load balancing, and sharding so applications can keep talking standard Postgres while the data spreads across multiple servers. The company says it has already handled multi-terabyte deployments and millions of queries per second, and will make sharding features open source while charging for a control plane, query QoS, and support. People who had actually used PgDog were broadly positive about stability and day-to-day usefulness, especially as a smarter pooler that can smooth Aurora failovers and solve some rough edges people hit with PgBouncer.
The strongest correction was about what the product is not. PgDog is a proxy, not a Postgres extension and not a new storage engine. Each shard is still ordinary Postgres with a single writer. That means it can spread load and isolate failures across many primaries, but it does not erase the core write bottleneck inside each shard or turn Postgres into Dynamo. Several comments also pushed back on the blog's wording around high availability. PgDog can route around unhealthy backends, but replica promotion still needs an external system like
Patroni,
CloudNativePG, AWS
RDS, or Aurora. Read it as one
HA component, not the whole HA story.
A lot of the conversation converged on where this class of tool actually fits. For read-heavy or modest workloads, a big Postgres box plus replicas, caching, and maybe PgBouncer still goes very far. The pain starts with write-heavy
OLTP, tenant isolation, operational blast radius, and teams that want to keep SQL and Postgres instead of redesigning around a key-value store. People compared that tradeoff with Dynamo, Mongo,
Citus,
Yugabyte,
Vitess-style systems like
Neki and
Multigres, and application-side sharding. The practical consensus was that PgDog is appealing when you want to keep existing Postgres applications and scale incrementally, but it does not remove the hard parts forever. Resharding, cross-shard consistency, query routing limits, version upgrades, and vendor concentration are still where the real work lives.
The thread also spent time cleaning up the marketing. Claims like “100,000s of grocery delivery orders per minute” at Instacart were widely read as sloppy phrasing for database operations, endpoint traffic, or some broader internal metric rather than literal customer orders. That skepticism did not really undercut the product. It mostly reinforced that infrastructure buyers want precise numbers and narrow promises, especially when the software sits directly in the database path.