A three-person startup wants to settle the database debate by turning Postgres into something that shards and scales like the systems people usually reach for instead. With $5.5M behind it and 1.4M Docker pulls already, PgDog is betting that the only thing wrong with Postgres is the ceiling.

PgDog is making a bold claim, and it has decided to put $5.5M behind it: Postgres is the only database most companies actually need, and the reason teams keep adopting Mongo, DynamoDB, and other alternatives is not because those systems are better but because Postgres hits a scaling wall. Remove the wall, the argument goes, and the case for the alternatives gets a lot thinner.
The company building that argument is a proxy that sits in front of Postgres and makes it horizontally scalable. You point your application at PgDog instead of directly at the database, and it handles sharding and query distribution underneath. The pitch is deliberately low-friction: pull the Docker image, change your DATABASE_URL, and let the proxy do the work. There is no managed-service lock-in attached to the core product. You can run it on-prem, in a colocation rack, in your own cloud account, or on a laptop.
The problem they are solving
Postgres is excellent until a single node stops being enough. A table grows past tens of terabytes, query volume climbs into the hundreds of thousands per second, and the usual answers start to look painful. You can pay for a bigger instance until you run out of bigger instances. You can build sharding logic into your application, which spreads database concerns across your codebase and turns every schema change into a coordination problem. Or you can migrate to a database that was designed to shard from the start, which means rewriting your data layer and giving up the maturity of the Postgres ecosystem.
PgDog is trying to make the first option, keeping Postgres, viable at a scale where teams currently feel forced to abandon it. The proxy approach matters here because it keeps the database itself untouched. It is, in the company's words, "same old Postgres, just with a proxy in front of it." Applications still speak the Postgres wire protocol. Existing tools, drivers, and operational knowledge still apply. The sharding happens at the proxy layer, where queries can be routed to the correct shard and results assembled back together.
Traction before the round
The numbers PgDog is reporting are not projections. The company says it is serving more than 2M queries per second in production across dozens of deployments, and that it has sharded more than 20 TB of data that it knows about. Because the product is open source, the team does not have full visibility into who is running it, which is the natural consequence of shipping software people can simply deploy. The clearest public signal is distribution: over 1.4M Docker pulls.
The release cadence is unusually disciplined for an infrastructure project this young. A new version ships every Thursday. The team maintains an active Discord community and answers questions there daily. For an open source database proxy, where operators need to trust that someone is paying attention when something breaks at 2 a.m., that visible, regular presence is part of the product.
Why a three-person team thinks it can do this
The obvious question for any small startup asking you to put your data in its path is why you should trust it. PgDog's answer is the founders' history with the exact problem. The team describes itself as a mix of infrastructure engineers, application engineers, and generalists who built on Postgres at scale before the current wave of Postgres enthusiasm.
Lev, the founder writing the announcement, ran Postgres at Instacart and was there when the company scaled roughly 5x in April 2020, the early pandemic surge that pushed grocery delivery volume to hundreds of thousands of orders per minute. The hard part, by his account, was making Postgres keep up. The team sharded Postgres across RDS, Aurora, and EC2 and solved the problem with first principles and a lot of code. PgDog is the same class of solution, rebuilt as an open source product rather than internal infrastructure. The team frames this as continuity rather than a pivot: scaling Postgres has been the goal the whole time.
There is a practical engineering claim worth noting too. PgDog is multithreaded and will use every CPU you give it, with no dependencies or serverless billing surprises hiding in the architecture. For teams that have watched serverless database bills scale faster than their traffic, the promise of predictable, self-hosted cost is a real selling point.
The money and the plan
The $5.5M round comes from Basis Set, Y Combinator, Pioneer Fund, and other investors. For a three-person team running lean, that is described as years of runway, which is the kind of timeline an infrastructure product needs. Databases are not won in a quarter. Operators adopt them slowly, prove them in non-critical systems first, and only later trust them with the workloads that matter. Runway measured in years is closer to the minimum than the luxury here.
The commercial plan follows the familiar open core shape. The core proxy stays open source and freely deployable. Revenue is meant to come from an Enterprise edition aimed at making PgDog easier to run on AWS, bundled with SLA-backed support from the team. That structure tends to work when the open product is genuinely useful on its own and the paid tier removes operational burden rather than gating essential features. The 1.4M pulls suggest the free product clears the first bar; whether enterprises pay for the managed experience is the question the next few years answer.
The skeptical read is straightforward. Sharding a relational database transparently is one of the genuinely hard problems in data infrastructure, and the graveyard of projects that promised to make it painless is not empty. Cross-shard joins, distributed transactions, and rebalancing are where these systems tend to get complicated, and a proxy layer does not make those problems disappear so much as relocate them. Three people maintaining a weekly release schedule against that complexity is ambitious by any measure.
What makes PgDog interesting is that it is not asking anyone to believe in a future state. The production query volume, the sharded terabytes, and the download count exist now. The bet the investors made is that Postgres adoption keeps climbing and that a tool letting teams stay on Postgres past the point where they would normally jump ship has a durable market. If PgDog delivers on "make Postgres just work at any scale," it is selling something a lot of engineering teams have wanted for a long time. You can read the documentation to get started or follow the repository for the Thursday releases.

Comments
Please log in or register to join the discussion