Cloudflare Hyperdrive vs. Direct Connection Pooling: Latency, Connection Overhead, and P99 RTT on PostgreSQL

## Eliminating the Database Connection Overhead at the Edge

Executing relational database queries from serverless edge isolates presents a severe latency penalty: initiating a fresh TCP connection and TLS handshake across transcontinental links often adds 150-300ms of latency to an operation that requires only 5ms of database execution time.

### 1. Connection Architecture Comparison

| Architecture | Cold Connection Setup | Warm Query P50 | Warm Query P99 | Connection Saturation Handling |
|:-------------|:---------------------:|:--------------:|:--------------:|:------------------------------:|
| Direct from Edge Isolates | 240ms - 480ms | 112ms | 340ms | Rapid Exhaustion (Max 100-500) |
| Self-Hosted PgBouncer (Origin) | 160ms - 220ms | 98ms | 210ms | Transaction Mode Buffer |
| AWS RDS Proxy | 140ms - 190ms | 86ms | 185ms | Managed AWS Network Queue |
| Cloudflare Hyperdrive | 12ms - 24ms | 18ms | 42ms | Edge-Distributed Warm Pools |

### 2. Query Latency Breakdown

The latency equation for an unpooled query executed from Tokyo against an origin database in US-East:

$$\text{Latency} = \text{DNS} + 3 \cdot \text{RTT}_{\text{TCP+TLS}} + \text{RTT}_{\text{Auth}} + T_{\text{exec}} + \text{RTT}_{\text{Return}}$$

With an RTT of 75ms, connection setup alone consumes over 300ms. Hyperdrive reduces this to an in-data-center edge lookup:

$$\text{Latency}_{\text{Hyperdrive}} = \text{Edge Lookup} (<5\text{ms}) + T_{\text{exec}} + \text{Pre-Established RTT}$$