Skip to content

CONCEPT Cited by 1 source

Cold-start connection cost

Definition

Cold-start connection cost is the latency paid before the first query byte flows on a newly-opened database (or service) connection — the accumulated time of TCP handshake + TLS handshake + protocol-level authentication + first query round-trip. It is distinct from steady-state query latency (an already-warm connection executing a query) and from cold-start function invocation (concepts/cold-start, the serverless runtime spin-up) — though the two compose in practice: a cold function on a cold connection pays both.

Why this concept needs its own page

Benchmarks that report "MySQL query latency" typically conflate connection cost into the numbers silently, or exclude it by pre-warming the pool. For serverless / edge / ephemeral runtimes where every invocation is structurally cold, the connection cost is the latency budget. Naming it separately forces benchmarks to state which number they're reporting.

Canonical breakdown

For a MySQL binary-protocol cold connection over TCP+TLS 1.2:

  1. TCP 3-way handshake (1 RTT)
  2. Plaintext HandshakeV10 + capability negotiation (1 RTT)
  3. TLS upgrade via SSL_REQUEST + TLS 1.2 handshake (2 RTTs)
  4. MySQL authentication (caching_sha2_password) (1-2 RTTs)
  5. First query round-trip (1 RTT)

Total cold path: ~6 RTTs before query result lands.

For an HTTP/2 over TLS 1.3 cold connection with session resumption available:

  1. TCP 3-way handshake (1 RTT)
  2. TLS 1.3 handshake (1 RTT; 0 RTTs with resumption)
  3. HTTP/2 preface (0 RTTs, piggybacks on handshake completion)
  4. First request/response (1 RTT)

Total cold path: ~3 RTTs (fresh) or ~2 RTTs (resumed).

For an HTTP/3 over QUIC cold connection with session resumption:

  1. QUIC+TLS 1.3 fused handshake (1 RTT; 0 RTTs for 0-RTT resumption)
  2. First request/response (1 RTT, can be piggybacked)

Total cold path: ~2 RTTs (fresh) or ~1 RTT (resumed).

Canonical measurement

PlanetScale, 2023-01-04 (Source: sources/2026-04-21-planetscale-faster-mysql-with-http3): "Connect + SELECT 1" benchmark shapes (new connection each iteration, serial, from two network distances):

  • High-latency (Reno NV → us-west-2): MySQL min 162 ms vs HTTP min ~35 ms — ~4.6× reduction. MySQL max jumps up; HTTP max stays steady.
  • Low-latency (us-west-2 → us-west-2): MySQL 11 ms vs HTTP 3-4 ms — even at ~1 ms network RTT, the MySQL handshake stack adds ~7 ms of round-trip overhead HTTP doesn't pay.

Robenolt attributes the win primarily to TLS 1.3 adoption in the HTTP client (see concepts/tls-1-3-zero-rtt-handshake) plus connection multiplexing (a second and third request reuse the HTTP connection; the MySQL equivalent opens a fresh TCP+TLS+auth stack every time).

Why HTTP beats MySQL on cold start

  1. TLS 1.3 is universal in HTTP; still rare in MySQL clients. The HTTP ecosystem moved to TLS 1.3 years ago; MySQL client libraries typically negotiate down to TLS 1.2 even when the server offers 1.3. "While, in theory, MySQL clients could also support TLS 1.3, TLS support in clients is typically not great and, in this case, negotiated with TLS 1.2." (Source: sources/2026-04-21-planetscale-faster-mysql-with-http3.)
  2. MySQL wraps TLS inside its handshake; HTTP puts TLS on the bottom layer. The MySQL plaintext-first-then- SSL_REQUEST flow adds a round trip HTTP avoids.
  3. MySQL has a per-connection authentication round-trip after TLS; HTTP has at-most an application-level token header. Auth is ambient, not round-trip-gated.
  4. HTTP/2 and HTTP/3 streams over an existing connection have zero cold-start cost for the second-and-beyond request. See concepts/connection-multiplexing-over-http.

Why this matters for serverless / edge

Serverless runtimes cannot hold long-lived TCP connections across invocations — each invocation is structurally cold. So the cold-start connection cost is paid every request. A 160 ms MySQL cold start means a serverless API call takes at least 160 ms + compute; a 35 ms HTTP cold start takes a quarter of that. This is the forcing function behind PlanetScale's HTTP API alongside binary protocol pattern and the origin of the serverless-driver product family.

Distinction from other cold-start concepts

  • concepts/cold-start: serverless function cold-start — the runtime spin-up that precedes any user code. Includes container boot, VM boot, interpreter init, JIT warm-up. Independent of the connection, though often batched with the first connection cost.
  • concepts/ssl-handshake-as-per-request-tax: the TLS-specific subset of this cost when every request opens its own TLS session.
  • concepts/connection-time: Cloudflare's metric for client-side connection establishment time, including DNS
  • TCP + TLS. A web-browser framing of the same underlying primitive.

Seen in

Last updated · 550 distilled / 1,221 read