The only way to know you built the right thing is for someone else to use it. Technical founders spend years perfecting their code, only to realize the intended audience moved on.

When we launched PgDog over a year ago, the code wasn’t great. The connection pooler leaked, the load balancer misrouted queries and the sharding logic didn’t work at all.

Nonetheless, it was out there, not hidden behind a waiting list or a “coming soon” blog post.

That’s how we got our first bug report. A couple of days later, we got our second. A year later, we’re at 500 issues and counting.

Much like the not-so-secret formula for housing prices (location, location, location), the secret to good software is distribution. Give your code to your users and they will tell you what you did wrong, so you can fix it.

PgDog has two products: the open source and the enterprise editions. The open source version is published via GitHub, a Docker image and compiled binaries.

For each commit in the main branch, our CI pushes a Docker image to our public repository. We send those directly to our users.

On every tagged release, a GitHub action builds a Docker image and binaries for x86, ARM64 and Apple Silicon.

Our downloads counter is currently at 3.69M. Some of those are engineers giving it a try for the first time. Others are production deployments.

We even include a Debian package. You can download all of it here.

The enterprise edition is where things get more interesting. Instead of hiding it behind a long procurement process and NDAs, we made it publicly available. You can download it directly from our Docker repository:

PgDog

docker run ghcr.io/pgdogdev/pgdog-enterprise:v2026-11-02

Control plane

docker run -p 8080:8080
ghcr.io/pgdogdev/pgdog-enterprise/control:v2026-11-02

We also provide an open source Helm chart for you to deploy it into your Kube cluster. No auth, no contact form and no credit card required.

The download counters for those are higher: 5.16M for PgDog EE and 323k for the control plane.

We want you to use it and tell us what’s missing for it to work with your database.

Having our products easily accessible has made us work faster. A lot of code we ship, including enterprise-only features, is experimental. We release features as soon as they are written, usually gated behind a configuration flag.

A lot of our users run PgDog as part of their CI and in their staging environment. For example, if you’re using GitHub Actions, you can deploy PgDog in front of Postgres and just run your tests normally:

steps:

• name: Start PgDog run: | docker run -d --network host ghcr.io/pgdogdev/pgdog:latest
  pgdog --database-url postgres://postgres:postgres@localhost:5432/postgres
• name: Run tests env: DATABASE_URL: postgres://postgres:postgres@localhost:6432/postgres run: bundle exec rspec *_spec.rb

Our own integration tests catch a lot of bugs, but so do our users’. Together, we make sure that by the time PgDog goes to prod, it works.

Building proprietary software is harder. For example, PlanetScale had to build a fake Postgres extension to let you test your code against their new search product. The real thing only exists in their cloud.

PgDog is tested every day by thousands of engineers. Only 4 of them work at our startup. And that’s how we built production-grade sharded Postgres: one public Docker image at a time.