The further you are, the faster PgBeam gets.
Serverless functions in 20 global regions connect to a single PostgreSQL database in us-east-1, directly and through PgBeam. Each bar shows connect + p50 query latency, measured live in warm steady state. Across an ocean, PgBeam is dramatically faster. Next to the database, it stays out of the way. No synthetic data, no mocked endpoints.
Far from the database
17A direct connection pays a full cross-continent round trip on every connect and every query. PgBeam routes to the nearest region, serves repeat reads from the edge cache, and reuses warm pooled connections to the database. This is where the speedups are largest.
Portland
Waiting to run…
San Francisco
Waiting to run…
São Paulo
Waiting to run…
Dublin
Waiting to run…
London
Waiting to run…
Paris
Waiting to run…
Frankfurt
Waiting to run…
Stockholm
Waiting to run…
Dubai
Waiting to run…
Mumbai
Waiting to run…
Singapore
Waiting to run…
Tokyo
Waiting to run…
Osaka
Waiting to run…
Seoul
Waiting to run…
Hong Kong
Waiting to run…
Sydney
Waiting to run…
Cape Town
Waiting to run…
Near the database
3When the client already sits beside the database, a direct connection is fast and the proxy adds little raw latency — sometimes a few milliseconds of extra network hop. That is the honest geometry. The cache still pays off: repeat reads return from the edge in single-digit milliseconds instead of re-querying the database.
Washington, D.C.
Waiting to run…
Cleveland
Waiting to run…
Montréal
Waiting to run…
Methodology
How these numbers are generated. No synthetic data, no cherry-picked runs.
Setup
Each region runs as a serverless function deployed to that specific edge location. The function makes real PostgreSQL connections over TLS to a database in us-east-1.
Displayed value
Connect + median query latency (p50): the time to open a connection (TLS handshake, authentication) plus run the query. This is what a serverless function pays each time it reaches the database.
Sampling
5 queries per scenario; the first is discarded as connection warmup and the slowest remaining proxy sample is dropped as a cold-start outlier. p50 from 4 samples using nearest-rank. Results are cached at the CDN and refreshed with live measurements.
Direct
Fresh TLS connection from the serverless function straight to the database. No proxy, no pooling, no caching. This is the baseline that you get without PgBeam.
PgBeam MISS
Same query routed through PgBeam with cache intentionally bypassed (the query runs inside a transaction). The query still executes on the database, but benefits from connection pooling holding warm upstream connections.
PgBeam HIT
Same query through PgBeam served from the edge cache. The result is returned without touching the database. This is the best case and what the “× faster” badge reflects.
Warm steady state, measured fairly
- • Before measuring, the proxy path is driven through several round trips to reach production steady state: the nearest region is serving traffic, its pooled connections to the database are warm, and the cache is primed. This is the state an actively-used deployment is always in. We do not count the one-time spin-up cost a region pays after sitting idle.
- • The direct baseline is not warmed: a function connecting straight to the database gets no pool and no cache, so a fresh connection is exactly the baseline to beat.
- • Numbers are reported as measured. When a client sits right next to the database, the proxy can add a few milliseconds of network hop and the cache HIT may not beat a direct connect+query outright — we show that honestly rather than hide it. The wins grow with distance from the database.
- • The “× faster” badge compares cache HIT total vs direct total, and only appears when PgBeam is actually faster. Hover it to see the pool-only (MISS) speedup.
- • Results are cached at the CDN and refreshed in the background with new live measurements. If a region hits a transient error, its last known good measurement is retained.