PLANETSCALE 2022-07-22 Tier 3

PlanetScale — Temporal Workflows at scale with PlanetScale: Part 1¶

Summary¶

Part 1 of a two-part product-pairing tutorial by Savannah Longoria (PlanetScale, 2022-07-22) introducing Temporal and framing PlanetScale's managed Vitess/MySQL substrate as the durable persistence layer for Temporal clusters at scale. The post is pedagogical more than internals-deep, but lands three durable architectural disclosures the wiki did not previously have canonical homes for:

Temporal cluster = four independently-scalable services. Frontend gateway (rate limiting, routing, authorisation), History subsystem (maintains mutable workflow state + timers), Matching subsystem (hosts task queues for worker dispatch), Worker service (handles internal background workflows). This decomposition is the concrete shape behind the abstract "Temporal is a durable-execution engine" framing — each subsystem is its own service scaled independently against its own load profile.
Persistence-layer SQL vs NoSQL trade-off framed explicitly: "If you choose SQL, you trade operational simplicity for scalability. If you decide on No-SQL, you trade scalability for operational complexity. If you choose PlanetScale, you get both: operational simplicity and scalability." Canonicalised as concepts/temporal-persistence-layer. Six categories of data live in the persistence layer: tasks to dispatch, workflow execution state, mutable workflow-execution state, event history (append-only log; the substrate Temporal replays from when rehydrating after a crash), namespace metadata, and visibility data (for queries like "show all running Workflow Executions").
Temporal already uses horizontal partitioning internally (workflows sharded across History-subsystem shards; Shilkov 2021 is the canonical sizing reference). Because Temporal's shard count composes cleanly with the backing-store's shard count, a horizontally-sharded persistence substrate (Vitess / Cassandra) lets you scale both independently. Longoria's framing: "Since Temporal also uses horizontal partitioning, Temporal maps effortlessly onto PlanetScale and can take full advantage of PlanetScale's scalability improvements over a single MySQL instance."

The post also canonicalises Temporal's rehydration mechanism verbatim: "Temporal captures the progress of a workflow execution (or workflow steps) in a log called the history. In case of a crash, Temporal rehydrates the workflow; that is, Temporal restarts the workflow execution, deduplicates the invocation of all activities that have already been executed, and catches up to where it previously left off." This is the concrete realisation of durable execution via event-history replay — the Temporal-specific instance of the step-sequencer / workflow-engine shape described on the durable-execution concept page.

Part 2 (not yet published at the time of ingest; referenced in the post's closing paragraph) will walk through setting up docker-compose against PlanetScale with manually-created temporal and temporal_visibility tables — the operator-facing production-configuration sequel.

Key takeaways¶

Temporal cluster is four independently-scalable services, not a monolith. The Frontend gateway handles rate limiting, routing, and authorisation; the History subsystem maintains mutable workflow state and timers; the Matching subsystem hosts task queues for worker dispatch; the Worker service handles internal background workflows. Each scales against its own load profile.
Temporal's persistence layer is pluggable between SQL and NoSQL with opposite trade-offs: SQL (MySQL / Postgres) gives operational simplicity but caps at single-node write throughput; NoSQL (Cassandra) gives horizontal scalability but inherits Cassandra's rich tuning surface. Canonicalised as concepts/temporal-persistence-layer.
Six categories of data live in the persistence layer: tasks to dispatch, workflow execution state, mutable execution state, event history (the append-only log Temporal replays from on crash), namespace metadata, visibility data. Event history is the concrete realisation of durable execution via write-ahead logging applied to user-space workflow code.
Workflow rehydration = event-history replay + activity deduplication. "Temporal restarts the workflow execution, deduplicates the invocation of all activities that have already been executed, and catches up to where it previously left off." Failure handling is entirely outsourced to the engine — the application developer writes normal code and Temporal handles retry, rollback, and long-running-timer semantics.
Horizontal partitioning composes. Temporal shards workflows internally (History subsystem) and Vitess shards tables at the storage layer. The two shard counts scale independently, so a PlanetScale-backed Temporal cluster inherits Vitess's scalability without Temporal-side re-architecture. Shilkov's 2021 post is the canonical sizing reference.
Long-running ≠ long-in-wall-clock-time. "Long-running isn't really about some arbitrary cutoff in time — it can be short or infinitely long." The canonical long-running workflow examples Longoria cites are Box (file-update orchestration, hours for large transfers but feels instantaneous to users — Temporal for transactional + reliability guarantees around microservice orchestration) and Checkr (background checks, days, because the process might dispatch a court researcher to a physical courthouse — Temporal persists event history as source of truth for both observability and reliability). E-commerce use cases cited: loyalty rewards, subscription charges, reminder emails over the entire customer relationship lifetime.
Four dev-only deployment paths: Docker Compose, Render Blueprint, Helm charts, Gitpod. Explicitly called out as not production configurations — useful only for local development and testing. Part 2 (not yet published) covers the production shape.

Systems mentioned¶

systems/temporal — the post's central subject. The four- subsystem decomposition (Frontend gateway, History subsystem, Matching subsystem, Worker service) is the load-bearing new architectural disclosure this ingest contributes to the Temporal system page.
systems/planetscale — the post's product-pairing counterpart. PlanetScale is framed as the persistence layer that collapses the SQL-vs-NoSQL trade-off (operational simplicity and scalability).
systems/vitess — the sharding substrate beneath PlanetScale MySQL; the mechanism behind the "takes full advantage of PlanetScale's scalability improvements over a single MySQL instance" framing.
systems/mysql — one of the two SQL options Temporal's persistence layer supports.
systems/postgresql — the other SQL option Temporal's persistence layer supports.
systems/apache-cassandra — the NoSQL option Temporal's persistence layer supports; the "scalability but operational complexity" alternative.

Concepts extracted¶

concepts/temporal-persistence-layer — new canonical concept: Temporal's pluggable SQL-vs-NoSQL storage layer, the six categories of data it stores, and the operational-simplicity-vs-scalability trade-off framing.
concepts/durable-execution — extended: new Seen-in canonicalising Temporal rehydration (event-history replay + activity dedup + catch-up) as the concrete realisation of durable execution at the workflow-engine altitude. Complements the existing Instacart Maple / Cloudflare Project Think / Fly.io flyd ingests with the first wiki disclosure of Temporal's own mechanism in its own words.
concepts/fault-tolerant-long-running-workflow — cross-ref only: the event-history-based replay-on-crash shape this post canonicalises for Temporal is the same scale-derived correctness shape Lord's 2026-02-16 PlanetScale zero-downtime-migrations post canonicalises for Vitess VReplication workflows. Different substrate, same architectural discipline.
concepts/horizontal-sharding — extended: new Seen-in canonicalising Temporal's internal workflow-sharding and its composition with the persistence-layer's own sharding.

Patterns extracted¶

None created — the post is framing-first, not mechanism-deep, and the architectural disclosures slot into existing concept pages (durable-execution, fault-tolerant-long-running-workflow, horizontal-sharding) plus one new concept (temporal-persistence-layer). No new pattern pages warranted.

Operational numbers¶

The post is an introduction / product-pairing piece with essentially zero quantitative content. Numbers mentioned:

Four independently-scalable Temporal services (Frontend gateway, History subsystem, Matching subsystem, Worker service).
Six categories of data in the persistence layer (tasks, workflow execution state, mutable state, event history, namespace metadata, visibility data).
Two supported storage classes: SQL (MySQL + Postgres) and NoSQL (Cassandra). PlanetScale framed as a third option that collapses the trade-off.
Four dev-only deployment paths: Docker Compose, Render Blueprint, Helm charts, Gitpod.
Millions of concurrently-running workflows cited as Temporal's throughput ceiling (marketing-shape claim, not benchmarked in the post).
Box + Checkr named as canonical long-running-workflow production case studies.

No benchmarks, no latency numbers, no shard-count sizing, no concrete PlanetScale cluster topology — all operational detail deferred to Part 2.

Caveats¶

Introduction / product-pairing tutorial voice, not a deep architectural post. Architectural density ~30–40% of body concentrated in the middle third (Temporal cluster decomposition, persistence-layer data categories, SQL-vs-NoSQL trade-off). Borderline Tier-3 scope-pass: the four-subsystem decomposition + the persistence-layer-trade-off canonicalisation + the horizontal-partitioning-alignment framing are durable wiki contributions the existing Temporal system page did not have.
Part-1-of-2 post. Part 2 (not yet visible in the raw corpus as of this ingest) covers the production docker-compose setup against PlanetScale with manually-created temporal and temporal_visibility tables — the mechanism altitude this post promises and defers.
Savannah Longoria's first wiki ingest (she is the PlanetScale author of the 2026-04-21 How to read MySQL EXPLAINs post already canonicalised — that's her pedagogical-canonical voice; this is her earlier product-pairing voice).
PlanetScale-favourable framing for the SQL-vs-NoSQL trade-off: "If you choose PlanetScale, you get both" is the marketing-shape claim. The wiki canonicalises the trade-off itself (operational simplicity vs scalability) as the durable framing; PlanetScale's collapse of it is one implementation option, not a universal resolution.
No benchmark numbers for Temporal-on-PlanetScale at any scale. "Millions of concurrently-running workflows" is cited but not substantiated for the PlanetScale-backed configuration. All concrete numbers are deferred to Part 2 (or absent entirely).
Cassandra alternative under-developed. The NoSQL arm is named but its tuning surface (compaction, tombstones, repair, gossip cluster health) is not enumerated — the "operational complexity" framing is accurate but abstract. systems/apache-cassandra already canonicalises these; this post does not extend them.
Temporal's internal shard-sizing deferred to an external source (Shilkov 2021 blog post), not summarised in this ingest beyond the "Temporal uses horizontal partitioning" claim. The concrete choose-N-shards framework remains off-wiki.
No mention of Temporal Cloud (the managed Temporal SaaS offering). The post's mental model is self-hosted Temporal Server paired with a managed database — a valid shape but not the only one.