Skip to content

SYSTEM Cited by 11 sources

VTGate

What it is

VTGate is the application-level query routing layer in a Vitess cluster. It is the MySQL-protocol-speaking proxy that applications connect to; VTGate parses the query, consults the topo-server to determine which VTTablets (and therefore which underlying MySQL instances) the query should route to, and proxies the query to the selected tablet(s).

From PlanetScale's own description:

"VTGate is an application-level query routing layer… VTGate determines available tablets and their roles via the topo server and reroutes traffic as needed." (Source: sources/2026-04-21-planetscale-planetscale-vs-amazon-rds)

Role in the Vitess data path

VTGate sits at hop 3 of the five-hop PlanetScale MySQL data path:

application  →  edge load balancer  →  VTGate  →  VTTablet  →  MySQL
  (hop 1)          (hop 2)            (hop 3)    (hop 4)     (hop 5)

(Source: sources/2026-04-21-planetscale-planetscale-vs-amazon-rds, verbatim.)

VTGate's responsibilities:

  • Query routing: parse MySQL protocol, decide which shard(s) / which role (primary vs replica) the query targets, based on the VSchema and VIndex definitions.
  • Cross-shard query planning: for queries spanning multiple shards, generate a scatter-gather plan (see concepts/vtgate-query-planner, concepts/scatter-gather-query).
  • Read/write splitting: route writes to primary tablets, reads to replica tablets by tablet role (which VTGate learns from the topo-server).
  • Failover traffic redirection: when a tablet's role or health changes (VTTablet updates topo-server), VTGate "reroutes traffic as needed" without operator intervention.

What VTGate does NOT do

The division of labor against VTTablet is the load-bearing architectural split (see patterns/query-routing-proxy-with-health-aware-pool):

  • VTGate does not hold MySQL connections. The back-end MySQL connection pool lives in VTTablet.
  • VTGate does not directly health-check MySQL instances. It consumes the health state that VTTablet publishes to the topo-server.
  • VTGate is effectively stateless (inferred from the data path description — it reads topo-server on each routing decision; no durable state of its own that outlives a process restart). Multiple VTGate replicas can be run behind the edge LB without coordination, which is the enabling property for horizontal scale-out of the proxy tier itself.

Why that design

Keeping VTGate stateless + routing-only is what makes the PlanetScale MySQL platform's connection-scaling claims work: an application can open a very large number of client connections against VTGate, because VTGate doesn't need to hold a back-end MySQL connection per inbound client connection — VTTablet does connection pooling + queueing behind it. This is the mechanism Liz van Dijk's 1M-connection benchmark relies on (sources/2026-04-21-planetscale-one-million-connections).

Seen in

Last updated · 470 distilled / 1,213 read