Skip to content

SYSTEM Cited by 1 source

PlanetScale Singularity

What it is

PlanetScale Singularity is PlanetScale's internal infrastructure-management service. Per the 2024-07-30 Faster backups with sharding post (Source: sources/2026-04-21-planetscale-faster-backups-with-sharding), Singularity is the primitive PlanetScale uses to spin up ephemeral compute — specifically, the dedicated VTBackup instance that runs per shard per backup.

Verbatim: "This request gets passed on to PlanetScale Singularity, our internal service for managing infrastructure. This spins up a new compute instance in the same cluster as the primaries and replicas. This instance will handle running VTBackup, which manages the backup process."

Why it shows up on this wiki

Singularity is the ephemeral-compute primitive under PlanetScale's backup architecture. Without a cheap mechanism to spin up a fresh VTBackup instance per shard per backup cycle, the dedicated-backup-instance pattern would be operationally unattractive — each backup would be a capacity-planning exercise.

It is also the load-bearing enabler of concepts/shard-parallel-backup at 256 shards. The architectural property "backup wall-clock scales as N × per-shard bandwidth" only holds if N ephemeral backup instances can be launched at will; Singularity is the primitive that makes that cheap.

What's publicly known

  • Spins up new compute instances in the same cluster as shard primaries and replicas.
  • Called by the internal PlanetScale API in response to scheduled or user-initiated backup requests.
  • Scope is "managing infrastructure" — the post's framing suggests Singularity's scope is broader than backups, but only the backup-instance provisioning use case is publicly disclosed.

What's not publicly known

  • Whether Singularity is a PlanetScale-internal Kubernetes operator, a bespoke orchestrator, or a thin layer on top of cloud-provider compute APIs.
  • Whether ephemeral instances are short-lived (spawned per backup and destroyed) or pooled / warm.
  • Placement policy — same AZ as the primary? cross-AZ? spot-instance usage?
  • How Singularity coordinates with Vitess's vttablet lifecycle management.
  • Whether it is used for non-backup ephemeral-compute workflows (resharding, VDiff runs, migration instances).

Minimal-viable page for now — exists to anchor the PlanetScale Singularity name introduced by the 2024-07-30 post. Deeper treatment if PlanetScale publishes an internals post about Singularity.

Seen in

Last updated · 347 distilled / 1,201 read