Introducing PgBeam

The problem

If your PostgreSQL database is in us-east-1 and a request comes from a serverless function in Tokyo, an edge worker in Mumbai, or an application server in Frankfurt, the network round trip is 100–200ms.

But a new PostgreSQL connection isn’t one round trip. It’s at least four: TCP handshake, TLS handshake (2 RTTs), then PG startup and auth. That’s 400–800ms before the first query even runs.

Read replicas help but add operational complexity: replication lag, connection routing, ORM-level read/write splitting. PgBouncer pools connections but doesn’t cache. Hyperdrive does both but only works from Cloudflare Workers.

What PgBeam does

PgBeam is a PostgreSQL proxy that sits between your application and your database. It speaks the PG wire protocol, so any driver or ORM connects to it without code changes.

You only need to change the host in your connection string to route traffic through PgBeam:

HOST     = c7l12.us-east-1.rds.amazonaws.com
PORT     = 5432
USER     = user
PASSWORD = pass
DATABASE = postgres

HOST     = 02lj1xq6fasdfdra.gw.pgbeam.app
PORT     = 5432
USER     = user
PASSWORD = pass
DATABASE = postgres

PgBeam does three things:

• 1Routing. Via DNS, your connection string points to the nearest PgBeam proxy that has a pool of connections to your database.
• 2Connection pooling. Maintains warm upstream connections so your app doesn’t pay the TLS handshake + auth cost on every query.
• 3Query caching. SELECT results are cached at the edge. Writes, transactions, and queries with volatile functions (NOW, RANDOM, NEXTVAL) are never cached.

Benchmark

We publish a live latency benchmark that runs serverless functions from 20 global regions. Each function opens a real TLS PostgreSQL connection to a database in us-east-1, once directly and once through PgBeam. It measures full connect time plus p50 query latency across 5 samples (first discarded as warmup). No synthetic data, no cherry-picked regions.

For distant regions like Tokyo, São Paulo, and Mumbai, PgBeam typically reduces total round-trip time by 3–5x on cached reads thanks to edge-local responses. Uncached queries still benefit from connection pooling, which eliminates the multi-RTT TLS + auth handshake on every request.

How it compares

Limitations

• Read caching only. We do not replicate data, writes pass through to the upstream.
• Eventual consistency. Cached reads can be up to 60s stale by default. Caching can be disabled or configured.
• No cross-region cache sync. Each region’s cache is independent and expires via TTL.
• PostgreSQL only. There's no support for MySQL or other databases right now.

What’s next

PgBeam is in technical preview. We’re looking for customers and design partners from the waitlist and collecting feedback on real workloads. Here’s what we’re working on:

• Dashboard. A web UI for managing projects, viewing cache hit rates, and configuring TTLs per query pattern.
• More regions. We’re evaluating demand for additional regions to cover more of the globe with low latency.
• Vercel Marketplace. One-click provisioning as a Vercel add-on with integrated billing.

Running global infrastructure isn’t cheap. Right now, our focus is on validating PgBeam with real users and making sure the product delivers before scaling further. If you find this space interesting, please reach out.