Programming guides for beginner...
Any comments are welcomed....
I hope it helps!!! Thanks for drop by...

Thursday, June 11, 2026

PgDog Got $5.5M to Make Postgres Scale Horizontally

A three-person startup called PgDog closed a $5.5M seed round on 10 June 2026 — Basis Set led, with Y Combinator, Pioneer Fund, and a long tail of angels on the cap table — on the strength of a single product claim: their Rust proxy sits in front of Postgres and turns it into a horizontally-scalable database without changing the application. The numbers in the announcement — more than 2M queries per second in production, over 20TB sharded, 1.4M Docker pulls on the public repo, a release every Thursday — are the kind of production footprint that closes a seed round in 2026. The interesting question is what the funding is for, because the proxy is already shipping.

What PgDog actually does, and why "just a proxy" is the right shape

PgDog is a single Rust binary that lives between your application and one or more Postgres instances. It does three things, in the order they appear in the docs: connection pooling (the PgBouncer job), read load balancing (the HAProxy job), and sharding (the Citus job). The author's framing in the announcement is the framing that matters: "Same old Postgres, just with a proxy in front of it, to make it horizontally scalable. You can deploy PgDog anywhere, including on-prem and in your cloud account: pull our Docker image, change your DATABASE_URL, and make us do the work." That sentence is the entire product strategy. The DATABASE_URL swap is the deployment story, the make us do the work is the engineering story, and the Same old Postgres is the moat.

The technical shape of the three jobs is a single Tokio-based async runtime parsing Postgres wire-protocol traffic, deciding per-query where to send it, and (in the sharding case) rewriting cross-shard queries into per-shard queries plus a server-side aggregate. The author's own "vs. Citus" post draws the architectural line in the right place: "PgDog is using threads. Well, to be exact, it's using tasks, which are executed on a multi-threaded asynchronous runtime, called Tokio." Versus Citus, which runs as an in-database extension on Postgres's process-based architecture and is therefore capped at the same ~5,000-connection limit Postgres itself has. Tokio concurrency is "much, much higher than a simple multi-threaded process," and for I/O-bound traffic (which is what a connection pooler and read balancer are, 100% of the time) the difference is the whole product.

The 2M-qps number in the announcement is the load-balanced-plus-pooled number, not the sharded number. The author is candid in the HN thread that load balancing and sharding need to parse the query (not just forward bytes), so memory per pod can climb to a GB or more "if you have a lot of unique SQL queries (unique by text, not by parameters). We cache query ASTs to avoid parsing them on each request — that's the bulk of memory usage." That is the operational fact that decides whether PgDog fits in your architecture: at low query-cardinality OLTP, the proxy is essentially free; at high-cardinality analytics, you start paying the parse cost in RAM and CPU. The cross-shard aggregate rewriting is the feature the original Show HN comment thread was most excited about — "transparently injecting count() for average calculations sounds straightforward but there are so many edge cases once you add GROUP BY, HAVING, subqueries, etc." — and is the part the user pays the most for.

The funding story: Basis Set, YC, and the "Postgres-only" thesis

The thesis in the announcement is stated as a sentence worth quoting directly: "Postgres is the only database you need. The reason DBs like Mongo or Dynamo exist is because Postgres has a scaling problem. If you could make it just work, with 100 TB+ tables and 1M queries per second, we don't think you would use anything else." The "we are the team for this" half of the story is the founder's resume: "I ran Postgres at Instacart, where we scaled the company 5x in April of 2020. The biggest problem we had was making Postgres serve 100,000s of grocery delivery orders per minute. We sharded Postgres on RDS, Aurora and EC2." That is a specific, defensible claim about the founder being the right person to sell this product to the people who have the problem.

The strategic shape of the round is what the announcement does not say. The post closes with a P.S. that names the actual revenue path: "We are building an Enterprise edition of PgDog to make us easier to run in AWS. It comes with SLA-backed support from our team." The open-source product is the demo. The funded company is the SLA. That is the same shape as every successful OSS-infrastructure company since 2015: the binary stays free, the AWS integration is the invoice.

The HN thread picked up on the same shape, sometimes approvingly, sometimes not. "How are 3 developers going to QA this properly?" asks one commenter. "How are 3 developers going to sell that to any company? Procurement will have a field day." The reply that follows is the one that gets the bet right: "They have funding. That's what it will be for." And further down, the AWS-RDS-Proxy risk surfaces in two lines: "As long as they don't get undercut by the equivalent of AWS RDS Proxy which is a managed pgbouncer." That is the live competitive question and the round does not answer it; the round funds the team that has the best chance of answering it.

Where PgDog fits — and the line between "do not bother" and "switch today"

The 2026 landscape of "things you can put in front of Postgres" is crowded, and the honest answer to "which one" is conditional on scale. PgBouncer is the default — single-binary, written in C, used by every Postgres shop on the planet that needs to handle more client connections than the server can hold. PgBouncer does pooling. It does not do parsing-based load balancing. It does not do sharding. Citus is the default for sharding, an in-database extension owned by Microsoft since 2019, deeply integrated with the query planner, strong on OLAP workloads, weaker on OLTP because the process-based architecture caps concurrency. PgCat is the in-between option, a Rust-based pooler/balancer from the Citus team. AWS RDS Proxy is the managed option, a hosted PgBouncer with a price tag.

The user's three-way comparison is the one most people will do. If you are on a small Postgres, doing tens of connections at a time, do not add a proxy. The cost is real, the benefit is zero. If you are on a single Postgres, doing hundreds to low-thousands of connections, and you want a defense-in-depth measure against connection storms, PgBouncer is the boring answer. If you are at the point where one Postgres is no longer enough — either because the data is too large or the write rate is too high — PgDog is now the answer that comes with a company behind it. That is the line the $5.5M is buying the right to draw.

The execution risks the announcement is honest about

Two risks are visible in the funding post and the HN thread, and they are worth naming because they are the same risks that killed the last three Postgres-proxy attempts.

The first is the config surface. The complaint from a production user in the HN thread is direct: "I tried out PgDog a while ago, but couldn't find a good way of handling the config except for having this users / pgdog toml file, which makes it a bit awkward to handle in kubernetes where we often do multi-tenancy in postgres — or rather having many databases on the same instance(s), and have them come and go at will." The reply from another production user describes the workaround they shipped in production: "Happy to chat about this, but we use the AWS secrets manager flowing into External Secrets Operator to generate a pgdog_users.toml… You could also build a watcher side car that watches for changes of the pgdog_users.toml and have pgdog refresh itself then too with this combination. We thought about that but prefer to control the reloads for our needs." The pattern is familiar: open-source infrastructure that is technically capable but operationally fiddly, with the users in the same thread documenting the workarounds they shipped. The funded Enterprise edition is what closes this gap; the open-source product is what surfaces it.

The second is the three-person team. The thread raises it twice. "How are 3 developers going to QA this properly?" and "How are 3 developers going to sell that to any company? Procurement will have a field day." Three engineers is enough to ship a proxy and a protocol parser. Three engineers is not enough to staff a 24/7 on-call rotation. The funding fixes the second problem; it does not fix the first. The 1.4M Docker pulls and the 2M qps in production are evidence the proxy is being depended on at scale; the question is what the failure-mode story is when one of those production deployments needs help at 3am. The Enterprise edition with SLA-backed support is the answer, and the round is what makes the answer real.

A third, smaller risk lives in the comment thread but is not in the announcement: the Kubernetes multi-tenancy use case the user describes is exactly the use case the OSS version is least ergonomic at, and it is the use case every Postgres-shop-on-K8s has. The next twelve months of PgDog's roadmap, on the strength of the comments, will be defined by whether the hot-reload work lands before or after the AWS-native enterprise work.

The original take: the proxy is now the product, and the database is the bill of materials

The single most important sentence in the funding announcement names what is being sold. "Same old Postgres, just with a proxy in front of it, to make it horizontally scalable." The product is the proxy. The database is the bill of materials. That is the inversion the Postgres ecosystem has been working toward for ten years, and the round is the first time a venture-funded company has been built on the inversion.

The 2010s version of this story was: you build a horizontally-scalable database, you put Postgres features in it (transactions, joins, secondary indexes), and you sell the result as a new database. That is what CockroachDB and Yugabyte did. The 2020s version of this story, the one PgDog is betting on, is: you keep Postgres as the database, you put the horizontal-scaling features in a proxy, and you sell the proxy. The reason this works in 2026 and did not work in 2016 is that the Postgres of 2026 is much better at being a backend for a proxy than the Postgres of 2016 was. Logical replication, the wire-protocol stability, the maturation of the extensions ecosystem, the operational tooling around Patroni and pgBackRest — every layer of the Postgres stack is mature enough that the database is a dependable, replaceable part. The 2M qps in production, the 1.4M Docker pulls, the 20TB sharded, are the receipts for the proposition that the Postgres of 2026 can sit behind a proxy and be the storage engine for someone else's product.

The corollary: the next two years of database-funding will flow toward companies that build the layer above the database, not the database itself. The $5.5M buys the calendar time it takes to turn a working Rust binary into a sellable AWS integration. If the AWS integration ships, the next round funds the next layer above it. If it does not, the binary is a great open-source project that someone else builds a product on top of, which is the Citus-bought-by-Microsoft outcome and a perfectly fine one. Both outcomes are good for the Postgres ecosystem. The question is which one PgDog's founders are optimizing for, and the Enterprise-edition P.S. is the answer.

What this means for you

  • If you run a single Postgres and you are not at the connection limit, do nothing. The cost of a proxy is real; the benefit at this scale is zero. PgBouncer is the boring answer if you have to defend against a connection storm.
  • If you are starting to think about sharding, PgDog is now a serious answer to the question "do I move to Citus." The OLTP positioning is clear and the company has the funding to be a real vendor.
  • If you are on Kubernetes and Postgres is multi-tenant, the OSS version's config story is not where you want it yet. Either budget for a sidecar config-watcher, or wait six months for the hot-reload work, or use PgCat.
  • If you are an SRE at a company that already runs PgBouncer in front of a single big Postgres, the migration is a config change, not a code change. The DATABASE_URL swap is the entire integration test. The decision is whether the operational gain (parse-aware load balancing, sharding option) is worth the second dependency.
  • If you are a Postgres-vendor competitor (Citus, Yugabyte, Cockroach), the proposition PgDog is selling is "Postgres, scaled, with the same DB." The bet has $5.5M behind it now.
  • If you are watching the open-source-infrastructure funding cycle: the shape of this round — Basis Set + YC + Pioneer Fund, three-person team, single binary, "Postgres-only" thesis — is the shape of the next dozen rounds. The pattern is now proven enough to fund.

What to do this week

# 1. Read the funding announcement in full. It is short
#    and the four paragraphs after "Why us" are the
#    most-quotable four paragraphs in the Postgres
#    infrastructure space right now.
#    https://pgdog.dev/blog/our-funding-announcement

# 2. Read the vs. Citus comparison. The threads-vs-processes
#    section is the one you'll cite when someone asks you
#    "why is this written in Rust."
#    https://pgdog.dev/blog/pgdog-vs-citus

# 3. If you have a non-trivial Postgres in your stack, run
#    PgDog in front of it for an afternoon. The Docker
#    compose demo is a single file, the binary speaks the
#    Postgres wire protocol, and your existing psql /
#    pg_dump / app code does not change. The point of the
#    exercise is to see the query parser logs and the
#    per-shard connection accounting, not to validate
#    production behavior.
docker-compose up   # spins up 3 shards + the proxy on :6432
PGPASSWORD=postgres psql -h 127.0.0.1 -p 6432 -U postgres
SHOW pgdog.shards;  # see which shard your query landed on

# 4. If you maintain a connection-pooler setup with
#    PgBouncer, run the pgbouncer-vs-pgdog benchmark the
#    PgDog team published. The numbers are not
#    dispositive for your workload, but the shape of the
#    curve (PgBouncer peaks earlier, PgDog scales further)
#    is the thing you will quote.
#    https://pgdog.dev/blog/pgbouncer-vs-pgdog

# 5. If you are an SRE budgeting for the next two years of
#    Postgres infrastructure, put "what happens if PgDog
#    becomes the default pooler" on the list. The bet is
#    funded. The bet is shipping every Thursday. The
#    question is when your procurement process catches up.

# 6. Star the repo. It is open source, the releases are
#    weekly, and the Discord is the place where the
#    roadmap questions are actually answered.
#    https://github.com/pgdogdev/pgdog

Related reads from this blog

  • Microsoft Just Put a Workflow Engine Inside Postgres — Same strategic shape, same year, same substrate. Microsoft shipped a workflow engine inside Postgres; PgDog shipped a scaling layer in front of Postgres. Both bets are that the open-source Postgres of 2026 is the substrate, and the value is built on top of it.
  • Redis 8.8: Your Lua Rate Limiter Is Now Obsolete — The "one primitive beats a stack of helpers" pattern. Redis shipped the rate limiter as a first-class type; PgDog is shipping the connection pooler, the load balancer, and the sharder as a single Rust binary. The bet is the same: the integrated primitive wins.
  • Scott Chacon Spent $15K and 45B Tokens Rewriting Git in Rust — A different funding-shape story. Chacon is rewriting Git in Rust with a $15K personal bill; PgDog is shipping a Rust proxy with a $5.5M VC bill. Both stories are about the Rust-credible-binary moment in open-source infrastructure.

Disclosure

This post was researched and drafted with AI assistance. Primary sources are listed in the Sources section below. Every numerical claim, every direct quote, and every architectural description is taken from a fetched and cached source — the synthesis, the framing, and the "what this means" angles are this post's own. Conflict-of-interest note: the founder Lev Kokotov (@levkk) is the primary author of the funding announcement, the vs. Citus comparison, and the HN comments cited above. The architectural claims (Tokio runtime, process-vs-thread comparison, OLTP-vs-OLAP positioning) are vendor assertions, not independent benchmarks. The strategic-shape analysis in the original-take section is this post's framing, not a claim sourced from PgDog. Funding-status note: the $5.5M seed round and the Basis Set / Y Combinator / Pioneer Fund participation are reported in the funding announcement linked below; secondary confirmation beyond the founder's post was not independently verified at the time of writing.

Sources

By Jiro at June 11, 2026
Labels: , , , , , , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)