Skip to content

CONCEPT Cited by 1 source

MySQL connection termination at edge

Definition

MySQL connection termination at edge is the architectural pattern of fully terminating the TCP connection, TLS handshake, and MySQL protocol handshake at an edge node in the POP closest to the client — rather than routing the raw client TCP all the way to the origin database — and then multiplexing the caller's queries back to the origin over a small number of long-lived, warmed, encrypted backhaul connections.

Canonical framing from PlanetScale's 2024-04-17 Global Network launch post: "we fully terminate the MySQL connection and TLS handshake at the outermost layer, closest to your application. And connection pooling happens here, similar to running an instance of ProxySQL in your datacenter. From this outer layer, connections are able to be multiplexed and tunneled back to your origin database over a small number of long held, encrypted connections that are already warmed up and ready to go." (Source: sources/2026-04-21-planetscale-introducing-global-replica-credentials.)

Why it matters

Without edge termination, every MySQL connection pays the full handshake cost over the client-to-origin round-trip:

  • TCP 3-way handshake — 1 RTT.
  • TLS handshake — 1–2 RTTs depending on version / 0-RTT.
  • MySQL protocol handshake — 1–2 RTTs (auth plugin, capabilities, server greeting exchange).

For a client in Sydney talking to a DB in us-east-1, each handshake round-trip is ~200 ms. An application opening a new MySQL connection pays 4–5× that — close to a full second before the first query runs.

Edge termination moves the handshake chatter onto the client-to-edge round-trip, which is ~5–20 ms under a well-placed POP mesh. The edge keeps a warm, pre-handshake- complete backhaul connection to the origin DB region, so the end-to-end setup cost becomes (client-to-edge handshake) + (one-query-round-trip to origin) rather than (multiple-handshake-round-trips to origin).

Canonical shape

client                 edge POP                  origin DB
  │                       │                          │
  │── TCP SYN ─────────▶  │                          │
  │    (client-edge RTT)  │                          │
  │── TLS handshake ────▶ │                          │
  │── MySQL handshake ──▶ │                          │
  │     "session open"    │   warmed backhaul        │
  │                       │◄── multiplexed queries ─▶│
  │── SELECT 1 ─────────▶ │    (edge-origin RTT)     │
  │                       │── SELECT 1 (muxed) ────▶│
  │                       │◄── rows ─────────────────│
  │◄── rows ──────────── │                          │

Structural trades

  • Faster cold starts + cheaper handshake, paid for in edge fleet complexity (POP density, mesh health-checking, control-plane-watched routing).
  • Connection count at origin decoupled from client fleet size — the edge layer absorbs connection-count pressure through multiplexing. Classic elastic-client / fixed-backend mismatch solved at the network tier.
  • TLS terminates at the edge — the edge fleet must hold the private key material for the customer-facing cert; the backhaul from edge to origin runs over its own TLS with the edge-to-origin cert.
  • Session state lives at the edge, not origin. If an edge node fails, the client may need to reconnect (to a new edge via latency-based DNS) — but the origin pool is unaffected.
  • Per-query routing without reconnection becomes possible — the edge can pick a different origin cluster per query (e.g. nearest replica, nearest healthy region) without the client observing any reconnect event.

Seen in

Last updated · 378 distilled / 1,213 read