Why a Postgres proxy belongs in every serious cross-border seller’s tool stack
If your e-commerce operation runs on anything more complex than a Shopify basic plan, your database is already a bottleneck you don’t see until it bites you. Connection saturation during a TikTok Shop flash sale. Timeouts when your Amazon repricer fires off 500 concurrent inventory updates. The dreaded “too many connections” error at 3 a.m. on Cyber Monday. Most sellers treat backend scaling as an infrastructure problem for “someone else” — their hosting provider, their engineering team, their RDS instance class upgrade. That’s a mistake. The reason I’m writing about PgDog — a Postgres connection pooler and sharding proxy that just launched on Product Hunt — isn’t because you should drop everything and install it today. It’s because the principle behind it is the single most underrated lever for scaling a cross-border operation: scale your data layer without rewriting your application. And that principle applies whether you run an Amazon FBA empire, a DTC Shopify store with 50k SKUs, or a multi-marketplace account management SaaS.
The real problem beneath the “connection pooling” label
Cross-border sellers don’t think about database connections until the site goes down during a Prime Day surge. But the symptoms are unmistakable: slow checkout, inventory sync failures, delayed order confirmation emails. The root cause is almost always that your Postgres server can’t handle the number of simultaneous connections your application opens during a traffic spike. Most e-commerce backends — custom ERP systems, inventory management tools, order processing pipelines — are built with naive connection management: every web request or background job opens its own database connection, and under load, the pool of available connections exhausts.
Traditional solutions like pgbouncer or AWS RDS Proxy handle connection pooling by mimicking a database server that multiplexes many client connections into a smaller pool of actual Postgres connections. That works, but it’s a stopgap. It doesn’t solve the deeper problem of read/write scaling. PgDog goes further: it offers transparent query routing across multiple Postgres instances, including sharding. As the maker Lev Kokotov put it, the tool is already “serving over 2M queries per second across dozens of deployments” and supports cross-shard transactions — meaning you can horizontally scale your database without changing a single line of application code.
For a seller running a custom inventory system that ties into Amazon, eBay, and Shopify, that’s huge. You can split your product catalog across multiple Postgres nodes, handle traffic from three different marketplaces hitting the same API, and never rewrite your SQL queries. Compare that to the alternative: re-architecting your data layer with something like Vitess or Citus, which requires extensive query rewriting and migration work. As one commenter on the launch noted, that “saves weeks of migration work.”
How PgDog differs from existing options
The most common question I see from sellers when they hear “connection pooler” is: “Why not just use RDS Proxy or pgbouncer?” Here’s the honest breakdown.
RDS Proxy and managed poolers
AWS RDS Proxy is a great managed service — if you’re all-in on AWS. It handles bursty workloads, fails over automatically, and integrates with RDS and Aurora. But it’s proprietary, expensive at scale (especially with cross-region traffic for multi-country sellers), and does not provide read/write splitting or sharding. You’re still limited to a single Postgres instance’s write capacity. PgDog, by contrast, is protocol-level and database-agnostic. It works with any Postgres — including serverless options like Neon or Supabase — and can route queries to multiple read replicas or shards transparently.
pgbouncer and pgpool-II
pgbouncer is lightweight and fast, but it’s a pure connection pooler. No sharding, no query routing. pgpool-II offers connection pooling, load balancing, and some failover, but its sharding capabilities are limited and its configuration is notoriously fiddly. Neither tool can handle a single transaction that spans multiple shards — a critical gap for any operation that stores sales data across country-specific databases (e.g., US inventory, EU inventory, APAC orders). When a buyer in Germany purchases a product that’s fulfilled from a US warehouse, your app needs to update both databases atomically. PgDog’s support for cross-shard transactions, as confirmed by Lev in the comments, makes it the first proxy I’d consider for multi-region e-commerce backends.
The transparency argument
What really sets PgDog apart, and what matters most for sellers who don’t have a dedicated database team, is the “without changing your app” claim. The maker underscored this: “The ‘scale Postgres without changing your app’ framing is the part that matters for teams that can’t stop to re-architect.” Most of the cross-border operations I consult for have a single monolithic backend built by a previous developer or agency. Rewriting queries to match a proprietary sharding scheme is a non-starter. PgDog intercepts Postgres protocol traffic, parses the SQL, and routes it to the right backend — your app remains “naive,” as one commenter put it.
Why Amazon sellers should care more than Shopify ones
Shopify sellers who rely entirely on Shopify’s built-in database and APIs have limited need for a Postgres proxy — their backend is Shopify’s problem. But Amazon FBA brand owners and marketplace account managers often run custom software for inventory forecasting, repricing, and multi-channel fulfillment. Many of these tools are built on Postgres. When your Helium 10 integration pulls data into a local database, or your Jungle Scout extension writes to a SQL database for historical analysis, you’re creating a connection-hungry system. A single repricing algorithm can open dozens of connections per second. Add in Klaviyo webhooks hitting your backend, and you have a recipe for connection saturation. Amazon sellers who experience “server busy” errors during Q4 know this pain intimately. PgDog’s ability to pool and shard without app changes means you can drop it in front of your existing Postgres instance and immediately handle more parallel requests — a cheap fix compared to upgrading to a database instance with a higher connection limit.
What cross-border sellers can borrow from PgDog’s architecture
Even if you never install PgDog, the architectural thinking behind it is worth stealing for your own data layer planning. Here are three takeaways.
1. Separate scale from schema
Most sellers scale by throwing more hardware at the database — bigger instances, faster storage. That works up to a point, but eventually you hit the ceiling of a single machine. PgDog’s sharding model decouples your application’s view of the data (one logical database) from how it’s physically stored (multiple Postgres instances). You can start with a single instance and split it later without touching your code. For cross-border operations, this means you can add a new country-specific shard (e.g., db_brazil, db_japan) and route queries based on an attribute like country_code — all without rebuilding your checkout page or ORM layer.
2. Connection pooling is not a second-class concern
As one commenter noted, connection pooling is “one of those things you don’t think about until it bites you in production.” Sellers who run their own inventory management systems on DigitalOcean or Linode Postgres often hit the default connection limit (typically 100 or 200). Instead of raising the limit and risking memory exhaustion, deploy a pooling proxy. Even a lightweight setup with pgbouncer can increase your effective concurrency 10x. PgDog’s advantage is that it pools and routes, so you get more than just connection savings.
3. Test failover and shard rebalancing before you need it
One of the most insightful questions in the Product Hunt discussion came from Sabber Ahamed, who asked about shard map consistency during rebalance. Lev replied that the enterprise edition synchronizes config updates atomically across instances. For sellers, this is a warning sign: the open-source version may have a window where two instances of PgDog disagree on which shard holds a given record. That’s fine for development or read-heavy workloads, but for write-sensitive operations like order processing, you’ll want the enterprise edition or a custom health-check. The lesson: don’t assume “transparent” means zero risk. Test your failover scenarios with synthetic traffic spikes — Black Friday is not the time to discover a split-brain condition.
Where the math breaks
I have three reservations about PgDog as a drop-in solution for e-commerce operations, and they’re worth airing.
Latency overhead for high-frequency reads
The maker claims “very little overhead” compared to pgbouncer, but comments from Uddipta Mahanta rightly press on the tradeoff: “Wondering what the tradeoff on latency looks like under the hood, when it’s intercepting traffic on the fly, is there a noticeable overhead for high frequency, simple reads?” For a product catalog page that fires 20 simple SELECT queries per request, adding a proxy layer could add 1-5 ms per query if the proxy needs to parse and route SQL. That might be fine for an admin dashboard, but for real-time checkout flows or inventory availability checks during a flash sale, those milliseconds add up. I’d want to see benchmarks under e-commerce-style workloads — not just abstract 2M QPS numbers.
Cross-shard transactions: how transparent is transparent?
Hazy’s question cut to the chase: “does it coordinate the cross-shard write, or is keeping a transaction inside one shard still the app’s job?” Lev’s answer — “We support cross-shard transactions, so as long as we support the query your app is sending, it should work” — is reassuring but vague. Cross-shard transactions in a sharded system typically require two-phase commit (2PC) or distributed transaction protocols, which introduce latency and potential deadlocks. For sellers running high-volume order systems, a deadlock during checkout is a chargeback waiting to happen. PgDog may handle this elegantly, but until we see real-world incident reports, I’d keep your cross-shard transactions to a minimum — or ensure your app models are designed to keep related data (e.g., all orders for a single customer) on the same shard.
Where the math breaks: for small sellers
If you’re a single-country seller doing under $1M in annual revenue, don’t touch this. Your Postgres instance with 100 connections is fine. The complexity of running a proxy, managing shard maps, and debugging routing issues will cost you more in engineering time than it saves in database bills. PgDog is for the operation that has at least one dedicated DevOps person or a serious backend engineer. For everyone else, stick with Vercel Postgres, Neon, or Supabase — all of which handle connection pooling and basic read replicas out of the box, with less operational overhead.
What I’d watch / test next
Here’s my concrete checklist for the cross-border operator who wants to explore PgDog without getting burned.
This week, spin up a PgDog instance in front of your staging Postgres database. Use a load-testing tool like k6 to simulate a traffic spike: 200 concurrent connections hammering your catalog API. Measure the response times with and without PgDog. Especially watch for any increase in p99 latency on read-heavy queries. If the overhead is under 5ms, move to a test.
Next, test a cross-shard transaction by inserting an order that spans two shards (e.g., a multi-warehouse fulfillment). Verify that the transaction either commits both or rolls back both under failure conditions. Use a simple script that kills a database connection mid-transaction — does PgDog bubble up an error cleanly? That test alone will tell you if it’s safe for order processing.
Long-term, watch the project’s open-source edition for stability. The fact that it’s already handling 2M QPS in production is promising, but for e-commerce, uptime is everything. PgDog is config-driven and stateless, which means you can run multiple instances behind a load balancer — a solid HA story if you can afford the enterprise edition’s config sync. If not, you’ll need to handle shard map changes manually or accept inconsistency windows.
Finally, consider pairing PgDog with Neon’s serverless Postgres for a fully elastic data layer. Neon already pools connections automatically, but PgDog could add sharding on top — letting you run a single logical database that spans multiple Neon projects across AWS regions. For a seller with inventory in US, EU, and APAC, that could mean zero-downtime data scaling without touching your Shopify or Amazon integrations.
The bottom line: PgDog isn’t for everyone, but the idea behind it — scale the database without rewriting the app — is exactly the kind of leverage that separates a $10M seller from a $100M one. Test it, break it, and if it holds, you’ve just removed one of the biggest scaling bottlenecks in your stack.
