PgDog

What do they actually do

PgDog is an open‑source proxy that sits in front of PostgreSQL. Today it parses incoming SQL to route queries to the correct shard, provides connection pooling and load balancing, and uses PostgreSQL logical replication to move data between databases so teams can shard or reshard with minimal application changes (docs, query routing, resharding, github).

It also supports cross‑shard queries and aggregation at the proxy layer, with documented limitations for some aggregates and large sorts that are being expanded over time (cross‑shard, HN). Operators typically deploy via Docker or Helm, provide a routing config, point applications at PgDog’s listener, and monitor via an admin database and OpenMetrics endpoints (github, example config). The project is public and active (repo, releases, community) and is reported as used in production (github, YC profile).

Who are their target customer(s)

• Fast‑growing app teams outgrowing a single Postgres instance: They need to add capacity and move data without rewriting application code or taking downtime; PgDog’s proxy routing and online resharding aim to handle this outside the app (docs, HN).
• Teams on managed Postgres (RDS, Cloud SQL) that can’t change database internals: They need horizontal scale and query routing while keeping managed databases and applications unchanged, which a proxy layer can provide (site, docs).
• Product/engineering groups operating write‑heavy services: They struggle to move large row volumes between shards without downtime and need practical background data movement and cutover workflows (resharding docs, HN).
• Platform/SRE teams managing reliability and connection limits: They want pooling, load balancing, and actionable metrics/runtime controls for routing and health—areas PgDog targets with pooling and observability features (github, docs).
• Larger orgs needing enterprise‑grade controls and support: They require real‑time metrics, active query inspection, and vendor support beyond open‑source defaults, which PgDog’s Enterprise edition targets (enterprise docs, site).

How would they acquire their first 10, 50, and 100 customers

• First 10: Founder‑led pilots with active GitHub users and Show‑HN respondents, offering hands‑on deployment and a guided resharding test; use YC introductions and founder experience to reach fast‑growing Postgres teams (github, HN, YC).
• First 50: Publish step‑by‑step resharding guides and Docker/Kubernetes packages; run short technical workshops for SRE/platform teams; offer a paid, time‑boxed support package for production cutovers and convert pilots into paid users with case studies/runbooks (docs, github).
• First 100: Add solutions engineering, partner with Postgres consultancies/cloud integrators, ship a fixed‑scope resharding service, and list installers in marketplaces; productize gated enterprise features and standardize onboarding to scale subscriptions (enterprise docs, site).

What is the rough total addressable market

Top-down context:

Analyst estimates put the cloud database market around $52.4B in 2025; with relational at ~61% and PostgreSQL at ~16.85% of relational, the cloud Postgres workload pool is ~$5.4B. A 5–10% slice for third‑party tooling/services implies ~$270M–$540M as an initial PgDog TAM (MarketResearchFuture, Precedence/Grand View, Percona).

Bottom-up calculation:

If ~8,000 organizations run Postgres at a scale where sharding/resharding is relevant, and 20% adopt enterprise proxy/tooling at an average $80k ACV (software + support), the TAM is ≈ 8,000 × 0.20 × $80k = ~$128M. Including services that lift ACV to ~$120k would imply ≈ $192M.

Assumptions:

• Population of ~8,000 global orgs with Postgres workloads large enough to consider sharding/resharding.
• Initial adoption among that population ~20% for paid enterprise tooling/support vs. in‑house or free tools.
• Average annual contract value $80k–$120k blending software, support, and limited services.

Who are some of their notable competitors

• Citus (Azure Hyperscale): Extension/managed service that shards Postgres inside the database, turning tables into distributed shards; requires running a Citus‑aware Postgres cluster or Azure Hyperscale rather than adding a proxy in front of existing instances (docs).
• YugabyteDB: Distributed SQL database with PostgreSQL compatibility that replaces Postgres servers with a Yugabyte cluster to achieve horizontal scale (overview).
• PgPool‑II: Established Postgres proxy for connection pooling, load balancing, and replication‑aware routing; overlaps on ops features but lacks PgDog’s automated online resharding/cross‑shard orchestration focus (overview).
• PgBouncer: Lightweight connection pooler focused on multiplexing; widely used but does not handle sharding, query parsing/routing, or data migration (docs).
• ProxySQL: High‑performance SQL proxy with PostgreSQL support for advanced routing and query control; not purpose‑built for Postgres sharding/online resharding workflows (announcement, docs).