Skip to content

CONCEPT Cited by 2 sources

Connection multiplexing over HTTP

Connection multiplexing over HTTP is the subset of connection multiplexing that uses HTTP/2 or HTTP/3 streams as the multiplexing substrate — many logical request/response pairs sharing one underlying TCP+TLS (HTTP/2) or UDP+QUIC+TLS (HTTP/3) connection. When a database protocol is wrapped in HTTP, every logical database session becomes an HTTP stream on that shared connection, and the backend sees a small, stable pool of long-lived HTTP connections instead of a new TCP+MySQL+auth handshake per logical session.

Canonical statement

PlanetScale, 2022-08-18: "connection multiplexing with HTTP/2… all of which lead to a better experience for serverless environments." (Source: sources/2026-04-21-planetscale-introducing-the-planetscale-serverless-driver-for-javascript.)

PlanetScale, 2023-01-04: "The HTTP API multiplexes many traditional MySQL connections over a single HTTP connection, reducing the need to open many connections and maintain a connection pool." (Source: sources/2026-04-21-planetscale-faster-mysql-with-http3.)

Mechanism

  • HTTP/2: multiplexes streams on one TCP+TLS connection using binary framing. Each stream carries one request/response; streams are independent, can interleave, and inherit the connection's TLS state.
  • HTTP/3: multiplexes streams on one UDP+QUIC+TLS 1.3 connection. QUIC streams avoid HTTP/2's head-of-line blocking by delivering out-of-order at the transport layer.

Either way: N logical database sessions → 1 HTTP connection. The per-session cost of TCP handshake + TLS handshake + MySQL auth handshake is paid once, at HTTP connection establishment, and amortised over every subsequent request.

Why it matters

  1. Serverless runtimes can't afford per-invocation TCP handshakes. Each Workers / Edge function invocation is structurally cold; opening a raw MySQL connection per invocation would add ~100 ms+ to every request. A multiplexed HTTP connection is shared across invocations (or reused via the runtime's fetch() connection cache).
  2. Backend connection-pool pressure is decoupled from client count. A MySQL server has a hard connection ceiling (tens of thousands, constrained by per-connection memory and file-descriptor limits). If every serverless invocation held its own MySQL connection, the pool would exhaust at a fraction of the client scale. Multiplexing on HTTP means the backend sees a small, stable number of edge-to-origin HTTP connections — the edge does the fan-in.
  3. TLS state is reused across logical sessions. A new MySQL connection means a new TLS handshake; a new HTTP/2 stream on an existing connection has no TLS cost. This is the direct origin of HTTP's cold-start latency advantage measured in the 2023 benchmark post: "Connect + SELECT 1: MySQL min 162 ms vs HTTP min ~35 ms — a ~4.6× reduction."

Contrast with raw-TCP connection pools

A traditional MySQL client pool holds N open TCP+MySQL connections per client process. Scaling client process count → scaling backend connection count. Connection-pool exhaustion (concepts/connection-pool-exhaustion) is a classic failure mode at scale.

A proxy-tier multiplexer like Vitess's vttablet, Figma's figcache, or PlanetScale's Global Network edge already solves this for classical client fleets. HTTP-based multiplexing is the same idea baked into the client protocol itself: the HTTP client gets multiplexing for free from the transport, without needing a bespoke connection-pooling proxy in front of the database.

Relationship to concepts/connection-multiplexing

Parent concept. This page is the HTTP-transport-specific instance: same "N → 1" decoupling, same motivation, different implementation substrate. Figcache and Vitess multiplex on bespoke proxy tiers; PlanetScale HTTP API multiplexes on HTTP/2 streams. The choice between the two:

  • Bespoke proxy wins when the database wire protocol is richer than HTTP request/response (session-level state, long-lived cursors, prepared statement handles).
  • HTTP multiplexing wins when the client runtime cannot speak raw TCP anyway — the multiplexing comes for free because the runtime's HTTP client already does it.

Seen in

Last updated · 378 distilled / 1,213 read