PgDog is funded and coming to a database near you

Original Article ↗ Hacker News Discussion ↗

What PgDog Does

  • Acts as a PostgreSQL proxy providing:
    • Connection pooling
    • Read load balancing
    • Sharding / query routing across multiple Postgres instances
  • Sits in front of unmodified Postgres servers; not an extension or custom storage engine.
  • Aims to give an Aurora/Vitess-style experience, but purely at the proxy layer.

Performance & Architecture

  • Written in Rust for safety and speed, but main gains come from:
    • Offloading connection cost from Postgres processes
    • Distributing reads across replicas
    • Distributing writes via sharding to avoid single-node WAL / vacuum bottlenecks.
  • Production numbers mentioned include ~2M QPS; memory use largely driven by cached query ASTs.
  • Two approaches to large result sets that may OOM the proxy: crash & add RAM vs paging to disk; both acknowledged as trade-offs.

Sharding Model & Limitations

  • Current model: shard_number = hash(key) % num_shards; critics note this makes resharding expensive vs virtual-shard / range-based schemes.
  • Cross-shard transactions supported via 2PC, but:
    • Expensive and fragile under failures.
    • Recommended only for low-throughput “metadata” tables.
  • Reads can be eventually consistent; strong ACID across shards is not “faster than a single machine.”
  • Some automatic shard routing exists but is not well documented; often you must explicitly target shards.

Deployment & Configuration

  • Config driven by TOML files; several users report friction in highly dynamic, multi-tenant Kubernetes setups.
  • Workarounds include custom controllers/operators that regenerate config and trigger coordinated reloads.
  • Enterprise edition (paid) will add:
    • A control plane for multi-node management / “just works” deployment.
    • QoS features to block bad queries.
    • SLA-backed support.
  • Core sharding and scaling functionality is promised to remain open source; infra/UX around it is commercial.

High Availability & Upgrades

  • PgDog provides load balancing with health checks and failover routing, but:
    • It does not promote replicas; expects external HA tooling (Patroni, RDS, etc.).
  • Does not directly solve major Postgres version upgrades; discussion points to logical replication and pooler-based cutovers as the current norm.

Comparisons to Other Systems

  • vs PgBouncer/Pgpool-II: more features (sharding, smarter pooling, LISTEN/NOTIFY handling, per-connection settings), but more complexity.
  • vs Citus: Citus has richer OLAP/query engine; PgDog focuses on OLTP, proxy-based concurrency, and independent coordinator scaling.
  • vs Mongo/Dynamo/Cockroach/Yugabyte:
    • Thread notes that Postgres fundamentally remains single-writer-per-row.
    • Some argue KV/NoSQL systems scale writes more naturally; others prefer Postgres + sharding for its ecosystem.

Reception & Concerns

  • Many users report positive production experiences and smoother migrations vs PgBouncer.
  • Others question:
    • QA and operational risk from a small core team.
    • Supply-chain/security posture (reassured by maintainers’ review practices).
    • Marketing claims like “you wouldn’t use anything else,” seen by some as overstated.
  • Overall tone: excitement about more serious Postgres-scaling options, tempered by realism about sharding complexity and HA/upgrades still requiring careful design.