Case file — 52395CA3
Launch roast · Show HN
PgDog – Scale Postgres without changing the app by levkk · HN thread
Unsolicited, from public launch info only. Founder? Reply or ask us to take it down.
The idea
“PgDog – Scale Postgres without changing the app https://github.com/pgdogdev/pgdog Founder's Show HN post: Hey HN! Lev and Justin here, authors of PgDog (https://pgdog.dev/), a connection pooler, load balancer and database sharder for PostgreSQL. If you build apps with a lot of traffic, you know the first thing to break is the database. We are solving this with a network proxy that works without requiring application code changes or database migrations. Our post from last year: https://news.ycombinator.com/item?id=44099187 The most important update: we are in production. Sharding is used a lot, with direct-to-shard queries (one shard per query) working pretty much all the time. Cross-shard (or multi-database) queries are still a work in progress, but we are making headway. Aggregate functions like count(), min(), max(), avg(), stddev() and variance() are working, without refactoring the app. PgDog calculates the aggregate in-transit, while transparently rewriting queries to fetch any missing info. For example, multi-database average calculation requires a total count of rows to calculate the original sum. PgDog will add count() to the query, if it’s not there already, and remove it from the rows sent to the app. Sorting and grouping works, including DISTINCT, if the columns(s) are referenced in the result. Over 10 data types are supported, like, timestamp(tz), all integers, varchar, etc. Cross-shard writes, including schema changes (CREATE/DROP/ALTER), are now atomic and synchronized between all shards with two-phase commit. PgDog keeps track of the transaction state internally and will rollback the transaction if the first phase fails. You don’t need to monkeypatch your ORM to use this: PgDog will intercept the COMMIT statement and execute PREPARE TRANSACTION and COMMIT PREPARED instead. Omnisharded tables, a.k.a replicated or mirrored (identical on all shards), support atomic reads and writes. That’s important because most databases can’t be completely sharded and will have some common data on all databases that has to be kept in-sync. Multi-tuple inserts, e.g. Landing page content (pgdogdev/pgdog): # pgdogdev/pgdog PostgreSQL connection pooler, load balancer and database sharder. - Stars: 5552 - Forks: 294 - Watchers: 5552 - Open issues: 235 - License: GNU Affero General Public License v3.0 - Homepage: https://pgdog.dev - Default branch: main - Created: 2024-12-27T21:10:04Z ## Languages - C - Dockerfile - Elixir - Go - HTML - Haskell - Java - JavaScript - PHP - PLpgSQL - Python - RenderScript - Ruby - Rust - Shell ## Topics - load-balancer - pooler - postgresql - rust - sharding ## Top Contributors - levkk (917 contributions) - sgrif (148 contributions) - meskill (75 contributions) - jkaczman (41 contributions) - jaggederest (38 contributions) - murex971 (20 contributions) - niclaflamme (18 contributions) - dipeshbabu (16 contributions) - rlittlefield (7 contributions) - ygxio (7 contributions) --- ## README CI PgDog is an open source proxy for scaling PostgreSQL. It supports connection pooling, load balancing queries and sharding entire databases. Written in Rust, PgDog is fast, secure and can manage thousands of connections on commodity hardware. ## Documentation 📘 PgDog documentation can be **found here**. Any questions? Chat with us on **Discord**. ##### Enterprise edition 🏢 Enterprise edition (EE) documentation is available **here**. Changelog is available **here**. ## Quick start ### Kubernetes Helm chart is **here**. To install it, run: ```bash helm repo add pgdogdev https://helm.pgdog.dev helm install pgdog pgdogdev/pgdog ``` ### AWS If you're using AWS RDS, you can deploy PgDog using one of two supported methods: 1. Helm chart with EKS, or a self-hosted Kubernetes cluster 2. Terraform module to deploy PgDog on ECS ### Try in Docker You can try PgDog quickly using Docker. Install Docker Compose and run: ``` docker-compose up ``` Once started, you can connect to PgDog with psql or any other PostgreSQL client: ``` PGPASSWORD=postgres psql -h 127.0.0.1 -p 6432 -U postgres ``` The demo comes with 3 shards and 2 sharded tables: ```sql INSERT INTO users (id, email) VALUES (1, 'admin@acme.com'); INSERT INTO payments (id, user_id, amount) VALUES (1, 1, 100.0); SELECT * FROM users WHERE id = 1; SELECT * FROM payments WHERE user_id = 1; ``` ## Features 📘 **Configuration** All PgDog features are configurable and can be turned on and off. PgDog requires 2 configuration files to operate: 1. `pgdog.toml`: hosts, sharding configuration, and other settings 2. `users.toml`: usernames and passwords ### Exam”
The bull case
Postgres is the default database for fast-growing apps, and AI-era workloads are pushing more teams into write and query scaling pain sooner. The buyer's alternative is rewriting the application, so a drop-in proxy with credible production use is easy to justify at the panel's estimated $30–100k ACV. Direct-to-shard routing covers most traffic without distributed-query complexity, and the lead author's 917 commits show the depth to grind through the SQL-compatibility long tail, which is the real moat. Once a sharding proxy is in the data path, switching costs are brutal, so retention should be long. A disciplined investor would back this on lock-in plus an open-source funnel that costs almost nothing to run.
The panel
Grounded in live search01 Market
mixedThe live data names no competitors, funding figures, or market-size numbers, so I can't size the market or call it growing or saturated. Structurally, PgDog sits in a category of existing Postgres connection poolers, proxy-based sharding layers, and managed-database scaling features. Those incumbents are real, but I can't name them from the supplied data. Launch history shows only PgDog's own earlier HN post, which the founders reference, and this Show HN at 326 points and 63 comments. No prior failed attempts or post-mortems appeared. The biggest market risk is that cross-shard queries are still incomplete, and the AGPL license plus a separate enterprise edition may slow adoption at larger companies. The strongest advantage is the zero-app-change pitch, backed by production use, 5,552 stars, 294 forks, and an active contributor base.
02 Tech
strongThe hardest problem is making a proxy behave like one Postgres without app changes. That means parsing SQL, rewriting queries (injecting count() so avg() merges correctly), and coordinating cross-shard writes. The 2PC design is the sharpest risk: PgDog intercepts COMMIT and issues PREPARE TRANSACTION, but it tracks transaction state internally. A proxy crash between phases can leave orphaned prepared transactions that hold locks and block vacuum. It also depends on max_prepared_transactions being enabled. Docs don't show a durable coordinator log, and 235 open issues suggest the edge-case tail is long. Still, the lead author's 917 commits, Rust, production use and shipped aggregates show real depth. Writing the proxy in-house is the right call. The moat is the accumulated SQL-compatibility long tail, plus AGPL deterring hosted clones. Direct-to-shard routing is well chosen: it covers most traffic and avoids distributed-query complexity.
03 Finance
mixedNo pricing or revenue is disclosed, so unit economics can't be verified. The model is open-core: AGPL core plus an Enterprise edition. Bottom-up CAC looks cheap (5.5k stars, 326-point HN launch), but stars aren't pipeline. Buyers are teams whose Postgres is hitting its ceiling. Their alternative is a sharding rewrite costing several engineer-quarters, so an ACV of roughly $30-100k (my estimate) fits the value. The risk is that self-hosters never convert, since the core already includes sharding and pooling. What breaks first at scale is support: a proxy in the critical data path demands 24/7 SLAs and hand-holding for cross-shard edge cases, which are still unfinished. A favorable trait is that once a sharding proxy sits in production, switching costs are very high, giving long retention.
04 Timing
strongWell-timed, slightly early on cross-shard maturity. Postgres is now the default database for fast-growing apps, and teams that outgrow a single primary face a painful choice between rewriting for sharding and migrating to a distributed database. A drop-in proxy sits between those options. Macro trend: Managed Postgres providers and distributed-SQL vendors are racing to make horizontal scale native. If hyperscalers ship good-enough sharding, the proxy's value shrinks. Window: Open, but it is narrowing. Cross-shard queries are still unfinished, and that is where buyers will test it. Favoring factor: Heavy write and query load from AI-era apps is pushing more companies into scaling pain, and they want a fix that avoids app rewrites.
Risks to manage
The free core may already be enough
The AGPL core already includes pooling and sharding, and the Finance Agent flagged that self-hosters may never convert. No pricing or revenue is disclosed. Stars aren't pipeline, and teams comfortable running a Rust proxy on Kubernetes are often the same teams who'll never write a check. The hurdle is drawing a line for the Enterprise edition that buyers actually need rather than merely want.
Crash-recovery durability on cross-shard writes
PgDog intercepts COMMIT and issues PREPARE TRANSACTION and COMMIT PREPARED, but tracks transaction state internally. The Tech Agent found no sign of a durable coordinator log. A proxy crash between phases can leave orphaned prepared transactions that hold locks and block vacuum, and it requires max_prepared_transactions to be enabled. With 235 open issues, the edge-case tail is long, and this is exactly where a data-path product loses trust once. Fix this before an enterprise buyer finds it for you.
The window is real but narrowing
Cross-shard queries are still unfinished, and the Timing Agent notes that's exactly where buyers will test it. Managed Postgres providers and distributed-SQL vendors are racing to make horizontal scale native, so a good-enough native option could shrink the proxy's value within roughly two years (the panel's estimate). Live search returned no competitors, so I can't size that threat. What you do have to out-ship is the "good enough" built-in option.
Blind spot
"No application code changes or database migrations" is a great line, but nobody gets to sharded Postgres without moving data. Going from one primary to N shards means choosing a sharding key, backfilling, cutting over, and possibly resharding later, all on a live production system. Queries without the sharding key quietly become cross-shard, which is the unfinished part. Customers will judge you on that first migration weekend, not on steady-state routing. If that weekend is scary, your zero-change pitch dies at the evaluation stage, however good the proxy is.
What would need to be true
At least a meaningful minority of production users must hit a need (SLAs, resharding, durability guarantees) that the AGPL core doesn't satisfy and are willing to pay roughly the estimated $30–100k ACV for it.
Cross-shard query coverage and 2PC crash recovery must mature fast enough that a proxy failure never becomes a data-integrity incident before managed Postgres vendors make native sharding good enough.
The first migration from an unsharded primary to shards must be repeatable and reversible enough that a platform team will approve it without rewriting application code.
Actions to take this week
Mine the 63 HN comments, Discord, and GitHub issues for companies running PgDog in production. Book 5 calls and ask: "What would you have paid to avoid your last scaling crisis, and what would your team need before signing a support contract?" A positive signal is a named budget line or a request for an SLA unprompted.
Write a one-page Enterprise packaging draft built on what those calls surface (for example crash-recovery coordination, resharding tooling, SLAs, and audit features). Show it to the same 5 people with a concrete price in the $30–100k range and note who pushes back on the number versus the features.
Build and publish a chaos test: kill the proxy between PREPARE TRANSACTION and COMMIT PREPARED, then show how orphaned prepared transactions are detected and resolved. If it's not durable yet, say so and ship the fix. Honest evidence here will do more for enterprise trust than any feature.
Publish a plain-English AGPL FAQ aimed at legal and security teams: what's triggered when running it as an unmodified internal proxy, and what isn't. Track whether the number of "can we use this?" questions drops.
Ask one production user for a public write-up of their migration from single primary to shards, including the sharding-key decision and cutover. A published case study is your best sales asset against the "built-in managed sharding is good enough" objection.
Work through these, then roast the idea again with what you learned.
No account needed. One email, no follow-ups.
Your idea is next
What would the panel say about yours?
You just read what four AI examiners found in someone else's idea.
Your startup has a fatal flaw. Find it before you build.