Skip to content

SYSTEM Cited by 14 sources

PlanetScale

What it is

PlanetScale (planetscale.com) is a managed relational database vendor offering:

Differentiators called out on the Cloudflare blog:

  • Query insights — per-query performance telemetry for finding slow SQL.
  • Agent-driven tooling for improving SQL query performance.
  • Database branching — schema / data branches for deploying code safely, including database changes alongside application changes.

Starting price anchored at $5/month for a single Postgres node.

Why it shows up on this wiki

PlanetScale is the canonical wiki instance of the patterns/partner-managed-service-as-native-binding pattern on Cloudflare's developer platform:

  • Customer provisions a PlanetScale database from the Cloudflare dashboard / API.
  • Database is billed to the Cloudflare account (self-serve or enterprise), with Cloudflare credits (startup programme, committed spend) redeemable against PlanetScale usage — an instance of patterns/unified-billing-across-providers applied to the storage tier (companion to the AI-tier instance from 2026-04-16's AI Platform unification post).
  • Customer code in Workers talks to the database through a Hyperdrive binding — same shape as Cloudflare-native bindings, no separate SDK.
  • Underlying cluster / pricing / feature set is standard PlanetScale — Cloudflare is a provisioning + billing aggregator, not a repackager.

(Source: sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers.)

The Cloudflare integration is plumbed so the customer "get[s] the exact same PlanetScale database developer experience" — access to the same PlanetScale SKUs, pricing, and all PlanetScale features including query insights, AI tooling, and branching.

Timeline on this wiki

  • September 2025 — Cloudflare × PlanetScale partnership initially announced (referenced but not separately ingested).
  • 2026-04-16 — Cloudflare dashboard provisioning + Cloudflare-billed rollout announced; "next month" ship target for Cloudflare-billed flow; auto-placement via DB-region-aware placement hints named as forward-looking.

Seen in

  • — canonical 2021-07-20 PlanetScale-on-Vitess product thesis. Deepthi Sigireddi (PlanetScale, Vitess Maintainer) publishes the "why we chose Vitess" essay roughly a year after the company's founding. Canonicalises the three-phase product-narrative arc ( developer-platform-over-substrate): "provision a database to use with an application … schema changes can still be made in a safe, asynchronous manner without affecting system availability … as the application scale grows, Vitess' sharding capabilities can be leveraged to maintain performance without downtime." Names the four-safety-feature quad that PlanetScale inherits from Vitess — automatic row limits, hot row protection, query consolidation, non-blocking schema changes — as features "that vanilla MySQL cannot and does not provide." Names the 10-second onboarding target as an explicit design constraint and Kubernetes as the substrate ("some secret sauce from PlanetScale" on top of Vitess's pre-existing K8s compatibility). Names concepts/database-branching and Deploy Requests as PlanetScale's answer to the schema-change-fear pain point — companion-altitude to posted exactly one week earlier. Canonical Vitess-expert-shortage framing as the commercial thesis. Pre-flight schema-conflict checking named as PlanetScale's addition on top of Vitess's non-blocking-DDL path ("we have built on top of that to automatically check for potential conflicts before a schema change is deployed").

  • — Brian Morrison II (PlanetScale, 2023-08-23). Canonical pedagogy-101 product-overview tour of the full PlanetScale-Vitess-MySQL stack in one post. Load-bearing verbatim claim: "Every database and branch on PlanetScale is an independent cluster." Canonicalises vtctld as the third Vitess primitive alongside VTGate + VTTablet — first wiki disclosure (see systems/vtctld). Canonicalises the vtctld-to-vtctld schema-clone mechanism for branch creation: "when you create a branch, we'll spin up a new Vitess cluster for it and (using the vtctld component of the two clusters) apply the schema of the source database branch with the one you just created!" Covers every platform layer in one linear walkthrough — Vitess + Kubernetes + edge routing + shadow-table schema change + schema revert window + restore-replay-validate backup + multi-AZ auto-failover + Query Insights query-pattern normalization + dual monitoring stack (per-database query telemetry + custom networking-adjacent observability) + security surface (connection string roles + SSO + service tokens + GitHub Secret Scanning partner). First wiki canonicalisation of the "6 AZs in AWS us-east-1" pedagogy datum and PlanetScale-as- GitHub-Secret-Scanning-partner. Brian Morrison II's fourth earliest PlanetScale wiki ingest (after 2022-10-21 What-is-Vitess, 2023-09-27 Scaling-K8s-clusters). Pedagogy-101 altitude — architecture density ~40% on ~1,800-word body concentrated in first half (Vitess + K8s + branching + edge routing); second half brief per-layer paragraphs summarising mechanisms canonicalised elsewhere.

  • — PlanetScale (2023-10-05). Co-canonical with the same-day Aurora-comparison sibling: identical paragraph re-asserting the 5-hop PlanetScale MySQL data path ("application, to a load balancer, to VTGate, to VTTablet, and then finally to MySQL"), the VTGate (stateless router) vs VTTablet (per-tablet pool + health

  • topo-server publisher) split, and the edge- infrastructure frontend LB that terminates MySQL connections at the closest edge location. Canonical trigger on the wiki for promoting systems/vtgate, systems/vttablet, and concepts/vitess-topo-server to dedicated pages — previously ~18 wiki sources named these components without an architectural page. The new patterns/query-routing-proxy-with-health-aware-pool pattern distils the general shape (stateless router + pool-owning per-backend middleware + shared-state store) that the VTGate + VTTablet + topo-server triple embodies — and that RDS's RDS Proxy is a narrower counterpart to (connection-pool-only, no cross-shard routing, no platform LB).

  • — PlanetScale (Taylor Barnett, 2022-03-24). Origin- point launch post for schema revert — pins the 30-minute revert window + "in seconds" revert-latency SLO and positions VReplication's MySQL- transaction-level granularity as the losslessness guarantee. Canonical doctrinal phrase: "you can treat your database like you treat your code."

  • — PlanetScale (Taylor Barnett, 2023-04-13). Synthesis post that threads together the full schema-change safety toolkit: small-frequent changes, expand-and- contract, feature flags, branching + deploy requests, automated deploy-request lint, warn-on-drop, non-blocking online schema change, Gated Deployments, schema revert, Insights regression detection, and backup-restore-to-branch recovery. No new primitives disclosed — positioned as 2023-era developer-advocate index of the existing corpus.

  • — Earliest CEO-voice framing of PlanetScale's three-pillar downtime-prevention story on the wiki. Sam Lambert (PlanetScale CEO, 2022-08-02) names the three downtime root-cause classes — "Human error, System immaturity, Application issues" — and maps each to a product mitigation: deploy-time warn-on- drop-if-recently-queried + instant schema revert for human error; Vitess-as-battle- tested substrate (GitHub/Slack/Etsy/Roblox adopters) for system immaturity; Insights real-time query monitoring with SQLCommenter attribution for application issues. Canonical first- source on the wiki of query telemetry as deploy-safety signal and warn-on-drop-recently-queried — the pattern where the deploy-request UI cross-references destructive DDL against the platform's own query log to warn "this table is in use" before the mistake ships, paired with instant schema revert as the recovery backstop. Architecture density ~20–25% of body; preserved as earliest-reference / CEO-voice positioning marker rather than as internals disclosure. Also the earliest wiki citation of Lambert's developer-experience doctrine: "Developer experience starts with approachability but is only maintained with reliability and scalability."

  • — canonical wiki datum that PlanetScale's native schema-change workflow (branching + deploy requests + safe migrations) and external declarative tools like Atlas CLI are rivals, not complements. Brian Morrison II (PlanetScale, 2022-09-16, re-surfaced 2026-04-21) demonstrates Atlas CLI against a PlanetScale MySQL branch but flags the operational trade-off: "when using Atlas with PlanetScale, you'll need to make sure you don't turn on safe migrations, as that will prohibit you from running DDL on production." Safe migrations block direct DDL against production, routing schema changes through PlanetScale's branching + deploy-request UI; Atlas operates by issuing DDL directly over the MySQL protocol. The customer picks one ceremony — the vendor-managed one (PlanetScale safe migrations) or the declarative-file-in-Git one (Atlas). Canonical new patterns/declarative-schema-management pattern + concepts/schema-as-code concept. The tutorial post demonstrates the simplest-possible flow (two commands, one column add) — operational trade-offs between the two ceremonies are not analysed further.

  • sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts — Sugu Sougoumarane's capstone essay closing the Consensus algorithms at scale series. PlanetScale (and Vitess underneath it) is named as the canonical worked composition of the series' two architectural recommendations: [[patterns/pluggable- durability-rules|pluggable durability]] (expressed via VTOrc's plugin API, with Sugu's comparative claim that it is "more powerful than other existing implementations") + [[patterns/lock-based-over- lock-free-at-scale|lock-based over lock-free at scale]] (four-advantage argument). All four lock-based advantages instantiated in Vitess: Vitess Operator graceful failover for software deploys, tablet add/remove, direct-to-leader consistent reads, anti-flapping inherited from Orchestrator via the VTOrc fork. VTOrc full-auto-pilot roadmap disclosed: "There are still a few corner cases that may require human intervention. We intend to enhance vtorc to also remedy those situations. This will put Vitess on full auto-pilot." Intellectual humility: Sugu does not claim the framework is the conceptual substrate, only the easiest to reason about.

  • — earliest preserved vendor-comparison voice on the wiki for PlanetScale. Jarod Reyes (PlanetScale developer advocacy, 2021-09-30 — re-fetched 2026-04-21) positions PlanetScale against AWS RDS on two axes: connection scaling ("While RDS limits connections to 16,000, PlanetScale has been designed to scale to nearly limitless database connections per database", with the 1M-concurrent-connections benchmark as the empirical anchor) and developer workflow ( non-blocking schema changes + database branching vs RDS's mysqldump-staged-environment + 13-step-provisioning ceremony). The canonicalising contribution is the new query consolidation concept + consolidate-identical-in-flight-queries pattern — Vitess's proxy-tier primitive that merges simultaneously-arriving identical SELECT queries into a single upstream execution and fans the result back to all waiting callers, preventing the specific thundering-herd shape where a slow hot-row query cascades into full-pool exhaustion. Reyes's canonical YouTube framing: "if 3 million people go to your YouTube video at once, Vitess will notice that multiple clients are simultaneously (or nearly simultaneously) attempting the same query and serve them all from the same connection." The post is marketing-voice, not engineering deep-dive (~30–40 % architectural density); consolidation internals (window duration, hash semantics, scope boundary) are named but not specified — subsequent Vitess-internals ingests should update the concept page when a Noach / Gangal / Sigireddi-altitude post discloses the mechanism specifics. Preserves the 2021-era market snapshot ("Aurora is still on MySQL 5.7" — since superseded) as historical context. Jarod Reyes becomes the fourth named 2021-era PlanetScale voice on the wiki alongside Phani Raju.

  • sources/2026-04-21-planetscale-benchmarking-postgres — PlanetScale's benchmarking methodology disclosure for its Postgres product. Names Telescope as PlanetScale's internal benchmarking harness; commits to three public benchmarks (latency, TPCC at 500 GB, OLTP read-only at 300 GB); specifies the reference i8g M-320 shape (4 vCPU, 32 GB, 937 GB NVMe) with primary + 2 replicas across 3 AZs; publishes reproduction instructions + benchmarks@planetscale.com feedback address. Canonical wiki instance of the new patterns/reproducible-benchmark-publication pattern and the new concepts/price-performance-ratio concept (price-performance is the fourth benchmark question PlanetScale explicitly commits to answering). Establishes the vendor-benchmark-with-audit-trail voice for PlanetScale, paired with the 2025-10-14 Postgres 17 vs 18 post as the results sibling of this methodology post.

  • — Vitess 21 release announcement canonicalises five architectural shipping-points for PlanetScale MySQL's underlying Vitess substrate: reintroduced atomic distributed transactions, experimental recursive CTEs, reference-table materialization via Materialize, dynamic VReplication workflow config, and multi-metric throttler shipping (with v22 backward-compat sunset). Also introduces new Vitess subsystems on the wiki: mysqlshell logical- backup engine (contributed by Slack Engineering — first external-company contribution into Vitess's backup subsystem), vexplain trace + vexplain keys observability surfaces (the latter usable against standalone MySQL too). Vitess Operator 2.14 adds VTGate HPA autoscaling + Kubernetes 1.31 + per- keyspace Docker image selection. VTOrc gains an errant-GTID count metric. PlanetScale MySQL customers inherit all of this substrate without operator-surface exposure to the Vitess version bump.

  • sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers — primary introduction. Canonical instance of a partner managed-database integration behind Hyperdrive on Workers.

  • sources/2022-12-02-highscalability-stuff-the-internet-says-on-scalability-for-december-2nd-2022 — PlanetScale Boost disclosure. Boost is a partial materialized-view engine layered on PlanetScale's Vitess/MySQL substrate, claiming up to 1000× query improvements by inverting read-time planning into write- time planning. From the 2022 PlanetScale blog (summarized in Todd Hoff's Dec-2022 roundup): "Instead of planning how to fetch the data every time you read from your database, we want to plan how to process the data every time you write… a plan where we push data on writes instead of pulling data on reads." Queries can still miss the view; Boost's engine is "smarter about resolving these misses." This is an implementation of Jon Gjengset's (Jonhoo's) academic Noria work on dynamic, partially-stateful data-flow for incremental materialized-view maintenance. See patterns/partial-materialized-views.
  • — Ben Dicken's pedagogical deep-dive on B-trees + B+trees as the foundation of InnoDB (the storage engine underneath PlanetScale MySQL via Vitess). Establishes PlanetScale's developer-education voice on MySQL internals — distinct from the product / launch / integration voice of the 2026 Cloudflare partnership post. First canonical PlanetScale first-party source on the wiki (previous ingests were third-party references from Cloudflare + HighScalability).

  • — PlanetScale vectors public-beta announcement. Vector columns + indexes live inside InnoDB as first-class durable structures, implemented on a transactional extension of SPFresh (the continuously -updatable descendant of SPANN). Canonical wiki instance of patterns/vector-index-inside-storage-engine — vector search collapses into the MySQL substrate with full SQL (JOIN, WHERE, subqueries), ACID, pre-/post-filtering, and Vitess-sharded scale into terabytes. Rejects HNSW (RAM-bound, rebuild-required) and DiskANN (worse latency, incremental updates "hard to map to transactional SQL semantics") on structural grounds.

  • sources/2025-03-13-planetscale-io-devices-and-latency — Ben Dicken's storage-latency-hierarchy pedagogical post, published alongside the Metal launch. Establishes the ~50 μs local NVMe vs ~250 μs EBS round-trip datum that is Metal's latency argument (see concepts/network-attached-storage-latency-penalty); establishes the GP3 3,000-IOPS default cap as a network-storage- only throttle that direct-attached NVMe doesn't pay; establishes the replication-for-durability argument (1%/month × 3 = 0.0001% chance of data loss) that lets Metal skip network-attached storage without abandoning the durability property that drove the cloud to it. First canonical PlanetScale post advocating local NVMe for OLTP.

  • — Nick Van Wiggeren's complementary reliability argument for Metal. Loads the fleet-scale EBS operational view: "multiple events on a daily basis" across PlanetScale's production fleet (concepts/performance-variance-degradation); the fleet-scale blast-radius multiplier (768 gp3 volumes → 99.65% active-event probability; see concepts/blast-radius-multiplier-at-fleet-scale); io2 not immune ("roughly one third of the time in any given year" at fleet scale); correlated-AZ-failure observed on io2 too (see concepts/correlated-ebs-failure). Canonicalises PlanetScale's operational mitigations on EBS — automated volume-health monitoring (read/write latency + idle % + write-file smoke test) + [[patterns/zero-downtime-reparent- on-degradation|zero-downtime reparent in seconds]] to a healthy cluster node — and the structural fix: shared-nothing on local NVMe delivered by Metal. Together with the 2025-03-13 post these two form the full Metal argument on the wiki (latency + reliability).

  • — Vicent Martí's disclosure of Vitess's SQL expression evaluation engine (evalengine) — the subsystem that evaluates scalar SQL sub-expressions locally inside vtgate whenever they operate on cross-shard aggregated results. The post walks through the multi-year replacement of the original AST interpreter with a bytecode-less virtual machine that compiles each sub-expression into a slice of Go closures (patterns/callback-slice-vm-go) using planner- derived static type specialization from MySQL's information schema. Performance: geomean −48.60% sec/op vs the original AST interpreter, faster than MySQL's C++ implementation on 4/5 benchmarks, and zero memory allocations on 4/5 benchmarks. Retains the original AST interpreter permanently as deoptimization fallback + one-shot evaluator + fuzz-oracle sibling. First canonical PlanetScale deep-dive on Vitess sub-engine internals on the wiki — a different voice from the storage-engine-internals posts (Dicken, Lambert) and the hardware-platform posts (Van Wiggeren's Metal + EBS posts): this is the compiler/interpreter voice from PlanetScale's engineering bench.

  • — PlanetScale for Postgres private-preview launch (Sam Lambert, CEO). Canonical wiki introduction of the PlanetScale for Postgres product — real Postgres v17 under a proprietary operator (not a fork) with a proprietary proxy layer (incorporating PgBouncer for connection pooling) handling automatic failover with query buffering. Metal direct-attached-NVMe architecture extended from MySQL to Postgres — "we can bring the maturity of PlanetScale and the performance of Metal to an even wider audience." Supports online imports from any Postgres v13+ + automatic zero-downtime Postgres version upgrades. Benchmark claim: "consistently outperform every Postgres product on the market, even when giving the competition 2x the resources" (numbers deferred to separate methodology post). 50-customer pain-survey frames the market — "regular outages, poor performance, and high cost" consistent across existing Postgres-vendor set (same three axes Metal-for-MySQL targeted). Vitess explicitly rejected for Postgres — canonical wiki introduction of patterns/architect-sharding-from-first-principles-per-engine via PlanetScale's new Neki sharding system (neki.dev, waitlist-only), architected from first principles rather than porting Vitess: "Vitess' achievements are enabled by leveraging MySQL's strengths and engineering around its weaknesses." Convex named as launch-window production customer migrating reactive database infrastructure. Fifth PlanetScale first-party ingest + first canonical PlanetScale-for-Postgres post on the wiki. Positions PlanetScale for Postgres structurally against RDS / Aurora Limitless / Aurora DSQL / Lakebase as the real-Postgres-on- direct-attached-NVMe shape — distinct from extend-via- extensions (DSQL) and compute-storage-separation (Lakebase).

  • — Sixth PlanetScale first-party ingest and benchmarking methodology post implicitly referenced by the 2025-07-01 PlanetScale for Postgres launch's "outperforms every Postgres product" claim. Ben Dicken's 96-run sysbench oltp_read_only sweep comparing Postgres 17 and Postgres 18's three io_method modes across EBS-backed and local-NVMe EC2 instances. Findings reinforce PlanetScale's architectural thesis across three axes: (1) Local NVMe wins every scenario — the i7i.2xlarge outperforms every EBS variant on every Postgres config / concurrency / range- size combination; (2) io2 loses on price-performance at $1,513.82/mo vs i7i's $551.15/mo (for the same vCPU/RAM) — empirical backing for the "EBS io2 is expensive and not worth it" position; (3) Postgres 18's new async-I/O modes don't rescue EBS — neither worker nor io_uring closes the gap to local NVMe. The post's counter-intuitive headline — io_uring does not dominate, and loses on network-attached storage at low concurrency — canonicalises patterns/background-worker-pool-for-async-io as Postgres 18's deliberate default and concepts/async-io-concurrency-threshold as the underlying phenomenon. Ben Dicken's third wiki ingest after 2024-09-09 B-trees and 2025-03-13 IO-devices; establishes PlanetScale as the vendor benchmark voice on the wiki (systematic, 96-config, single-operator, caveats acknowledged) complementing the database- internals voice.

  • — Eighth PlanetScale first-party ingest and canonical wiki deep-dive on how PlanetScale performs zero-downtime migrations at petabyte scale. Matt Lord (Vitess core maintainer, PlanetScale) walks the entire mechanism underlying PlanetScale's Database Imports feature: VReplication-based per-shard streams with consistent non-locking snapshots + GTID- pinned binlog replication catch-up, VDiff zero-downtime consistency verification, and MoveTables SwitchTraffic cutover with VTGate query buffering + reverse VReplication workflow for rollback. Typical cutover duration "less than 1 second." Establishes PlanetScale as a canonical reference instance of online database imports at petabyte scale — the 2025-07-01 PlanetScale for Postgres post announced the capability for the Postgres side (v13+ imports, mechanism undisclosed); the 2026-02-16 post reveals the mechanism in full on the MySQL side. Names patterns/read-replica-as-migration-source as the operational default so production primary sees zero migration-related load. Canonicalises fault-tolerance as a correctness requirement (not just a nice-to-have) for workflows whose duration approaches fleet MTBF. Extends the wiki's Vitess story from expression-evaluation (2025-04-05 evalengine) and vector- sharding (2024-10-22 Vectors) into the third major subsystem: data motion.

  • — Ninth PlanetScale first-party ingest and canonical wiki deep-dive on PlanetScale/Vitess's query-routing + transactional-write layer. Harshit Gangal + Deepthi Sigireddi (Vitess core maintainers at PlanetScale) canonicalise Vindexes (rows → keyspace_id routing tables) and the Consistent Lookup Vindex mechanism that avoids 2PC on every DML by ordering commits across three MySQL connections (Pre / Main / Post) with rollback in the same order — canonical wiki instance of patterns/ordered-commit-without-2pc. The architectural invariant ("The lookup Vindex table may be inconsistent with the user table but the results returned for the query remained consistent with the user table") is sufficient because the user data table is authoritative for user-facing queries. Canonical new orphan-row concept with lazy reclamation via duplicate-key errors on unique lookup columns + for update-locked authoritative-table verification before repoint. Third canonical Vitess-internals disclosure after the 2025-04-05 evalengine post + the 2026-02-16 VReplication/VDiff/MoveTables post — together these three bracket query-routing + transactional writes (this post), data motion (2026-02-16), and expression evaluation (2025-04-05) as the three non-storage subsystems of Vitess's runtime. Extends the PlanetScale voice on the wiki from the customer-facing product surface into the sharded-database internals axis, sibling to the Matt-Lord 2026-02-16 post on the data-motion axis.

  • sources/2026-04-21-planetscale-anatomy-of-a-throttler-part-2 — canonical wiki disclosure of Vitess's tablet throttler architecture from Shlomi Noach's voice. Fourth canonical Vitess-internals axis covered on the wiki — after expression evaluation (2025-04-05), data motion (2026-02-16), and query routing + transactional writes (2026-04-21) — this post opens the load-admission-control axis. Canonicalises the Vitess tablet throttler (one throttler per vttablet, shard-primary aggregating replica metrics for shard-scope queries, no cross-shard communication by design), the shard-scope vs host-scope distinction that routes workloads to the right throttler, [[concepts/ replication-heartbeat|replication-lag heartbeats]] (pt-heartbeat technique + binlog cost), throttler hibernation with client-retry as load-bearing compensation, [[concepts/throttler-fail-open-vs-fail- closed|fail-open vs fail-closed]] HA policy, and layered polling-interval staleness for agent-mediated topologies. PlanetScale inherits the tablet throttler as part of its Vitess-based MySQL offering — this post is also the wiki's canonical non-Matt-Lord, non-Vicent-Martí, non-Harshit-Gangal Vitess- maintainer voice on the platform.

  • — Taylor Barnett (PlanetScale) publishes the canonical wiki walkthrough of the expand-migrate- contract pattern for zero-downtime mutating-schema changes. Deliberately pattern-first, PlanetScale- second: the six-step sequence (Expand → Dual-write → Backfill → Read-new → Stop-old-writes → Delete) applies to any relational database; PlanetScale-specific machinery (branching, deploy requests, Insights as the Step-4 production-monitoring aide, MySQL 8.0 invisible- column support, the table-rename warning that implements the pattern at the platform level by refusing direct RENAME COLUMN DDL) is presented as convenience. Also canonicalises the five-reason structural argument against coupled database-schema and app-code deploys (concepts/coupled-vs-decoupled-database-schema-app-deploy). Introduces Taylor Barnett as a new named PlanetScale voice on the wiki (joining Dicken / Lambert / Van Wiggeren / Martí / Lord / Gangal / Sigireddi / Hazen / Noach); first wiki PlanetScale post with explicit generalisation beyond PlanetScale's platform.

  • — Phani Raju (PlanetScale, July 2022) on how PlanetScale ships per-password roles (read-only, write-only, read/write, admin) on top of Vitess's native static-config table-ACL mechanism. The post is the wiki's first disclosure of the user query frontend — the PlanetScale ingress service responsible for all user-facing functionality — and of how it bridges dynamic per-tenant credentials with Vitess's tenant-agnostic file-based authz. The four-field credential-DB schema (display_name, role, password_sha1_hash, password_sha2_hash) is stored in a dedicated external credential store; the frontend authenticates, looks up the role, and rewrites the MySQL-wire security principal to one of three synthetic usernames (planetscale-reader, planetscale-writer, planetscale-admin) before the query reaches vttablet. The data-plane ACL file is therefore identical across every customer database, one file with three users. Post enumerates four concrete failure modes of the alternative (pushing ACL state onto every vttablet pod): refresh-interval latency vs "credentials work immediately" user story, per-pod race conditions during rollout, pod-restart having no authoritative source, per-customer state explosion — and the 1:1 four wins of the external-store approach (instant effect, pod-independent state, restart-safe, universal config). Full shape canonicalised as the new patterns/external-credential-store-with-principal-rewrite pattern. Seventh-distinct Vitess-internals axis on the wiki — authorization — and the first canonical treatment of how a managed multi-tenant product composes with a static-config authz substrate. Introduces Phani Raju as a new named PlanetScale voice.

  • sources/2026-04-21-planetscale-behind-the-scenes-how-schema-reverts-work — Holly Guevara and Shlomi Noach on how PlanetScale implements an instant, data-preserving schema revert in its deploy-requests UI. The post canonicalises VReplication as the substrate for both forward online-DDL and the post- cut-over inverse-replication stream that makes revert free at revert time. Key platform claim: at cut-over, Vitess "does not terminate upon migration completion" — the shadow table + stream stay alive and are re-primed in the opposite direction so the old-schema table keeps up with every post- cut-over write, turning revert from a "restore-from- backup" event into a second freeze-point swap of two already-in-sync tables. New canonical concepts concepts/shadow-table, concepts/cutover-freeze-point, concepts/pre-staged-inverse-replication and patterns patterns/shadow-table-online-schema-change and patterns/instant-schema-revert-via-inverse-replication originate from this post. Worked example (ALTER TABLE users DROP COLUMN title) makes the column-projection asymmetry explicit: rows added post-cut-over survive the revert but reappear with NULL in the restored column — "expected and something you can clean up after the revert, if necessary." The revert mechanism exists as the emergency escape hatch complementing the expand-migrate- contract discipline from the companion backward- compatible-changes post: the disciplined approach avoids needing a revert; PlanetScale's mechanism rescues the team that didn't follow it. Introduces Holly Guevara as a new named PlanetScale voice.

Caveats / gaps

  • No internal architecture disclosed. PlanetScale's own storage engine, MVCC semantics, replication topology, failover behaviour, regional availability, and Postgres- compatibility caveats (vs vanilla Postgres) are not covered by the Cloudflare-integration post; they live in PlanetScale's own docs.
  • Starter price is pass-through. The $5/month figure is PlanetScale's pricing, not a Cloudflare-subsidised rate.
  • MySQL side less-illustrated on the Cloudflare post. Both engines are named co-equal, but every code snippet in the Cloudflare post is Postgres.

Seen in — building data pipelines with Vitess

  • — Matt Lord (Vitess core maintainer at PlanetScale) canonicalises the VStream gRPC API as the CDC entrypoint under every PlanetScale MySQL database: a single unified change stream spanning hundreds or thousands of shards per keyspace, with VGTID as the one progress checkpoint consumers persist. Four driver ecosystems compose on the API — Debezium, Airbyte, Fivetran, PlanetScale Connect — canonical wiki instance of the new CDC driver ecosystem pattern. Frames PlanetScale MySQL as the OLTP operational-truth tier that CDC pipelines pull from, with the target tier being customer-side data warehouses / data lakes / integration systems. The structural rule canonicalised for sharded MySQL fleets: "use a Vitess variant of the connector/driver rather than the MySQL one" — engine- native CDC tools are single-shard-blind on sharded Vitess. Twentieth PlanetScale first-party ingest.
  • — Canonical one-article enumeration of PlanetScale's seven- layer data-safety envelope. Sam Lambert (PlanetScale CEO, 2023-06-28) names the seven defensive layers as: (1) Vitess clustering substrate, (2) MySQL ACID, (3) semi-synchronous replication, (4) cloud block storage (EBS / GCPD) with multi- drive replication and self-healing, (5) safe migrations + Revert, (6) mandatory validated backups on every plan, (7) encryption-in-transit + encryption-at-rest + leaked-credential auto-invalidation. Canonical wiki framing: defence-in-depth posture where no single layer is load-bearing for the durability guarantee. Introduces two new canonical wiki concepts: concepts/leaked-credential-auto-invalidation ("If you accidentally push a PlanetScale database credential into a public GitHub repository, it will be automatically invalidated within seconds") and concepts/storage-engine-maturity-as-data-risk ("If you are trusting a storage engine that has been around for less than a decade, you are taking extreme risk with your most important asset: your data"). Marketing-heavy Sam-Lambert- CEO voice with ~30% architecture density; clears Tier-3 via the two novel concepts + one-article enumeration of the envelope.

Portals (2022+) — regional read replicas

PlanetScale Portals (launch post, Taylor Barnett, 2022-05-24) adds read-only regions to a PlanetScale MySQL database: one writing region plus N read-only regions that each hold a full replicated dataset, sitting close to the application tier. Canonical motivating number from the launch post: ~90 ms → ~3 ms per query for a Frankfurt app previously dialing a Northern-Virginia primary (select * from books limit 10). Pair with the session-cookie read-your-writes window (Rails DatabaseSelector, { delay: 2.seconds }) to preserve RYW across the cross-region replication lag. See systems/planetscale-portals for the full page and for the ingested source.

The 2022 per-region-credential connection model was later superseded by the 2024 launch, which collapses N per-region credentials into a single global credential resolved via the CDN-shaped PlanetScale Global Network. Portals itself — the "there is a read-only region here" resource — is unchanged; only the connection model evolved.

Serverless driver (2022-08-18) — HTTP API for edge runtimes

PlanetScale ships the PlanetScale serverless driver for JavaScript (launch post, Taylor Barnett + Matt Robenolt, 2022-08-18) — a Fetch-API-compatible @planetscale/database npm package that reaches PlanetScale over secure HTTP instead of the native MySQL binary protocol. The driver unblocks serverless / edge runtimes — Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions — that cannot open raw TCP sockets to speak the MySQL binary protocol. The driver is the first production consumer of the PlanetScale HTTP API ("Backing our new driver is a new HTTP API and global routing infrastructure to support it.").

The same launch announcement doubles as the first public mention of the PlanetScale Global Network — PlanetScale's CDN-like database-connectivity fabric — describing it as "a client connects to the closest geographic edge in our network, then backhauls over long-held connection pools over our internal network to reach the actual destination. Within the US, connections from US West to a database in US East reduce latency by 100ms or more in some cases."

Four HTTP-transport advantages called out in the launch post:

  • TLS 1.3 faster connections — MySQL clients typically negotiate TLS 1.2; HTTP clients get TLS 1.3 (incl. concepts/tls-1-3-zero-rtt-handshake|0-RTT resumption) for free.
  • HTTP/2 connection multiplexing — N logical MySQL sessions → 1 HTTP connection; serverless runtimes no longer need a per-invocation connection pool.
  • Protocol compression (gzip / brotli / snappy) on the wire — the MySQL binary protocol has no equivalent client-side compression story.
  • Global routing — queries from a US West client to a US East cluster land at the nearest PlanetScale edge; backhaul runs over warm pool.

The shape — HTTP API alongside binary protocol — is the pattern. See for the ingested source; see (Robenolt, 2023-01-04) for the benchmark retrospective validating this choice quantitatively.

PHP / Laravel on Lambda via Bref (2023-05-03) — ecosystem integration

A secondary canonical deployment shape surfaces in the 2023-05-03 Matthieu Napoli post (): PHP applications deploy onto AWS Lambda via Bref and reach PlanetScale over the native MySQL binary protocol (not the HTTP-API driver, because Lambda can open TCP, unlike Cloudflare Workers / Vercel Edge). PlanetScale-specific .env surface area:

DB_CONNECTION=mysql
DB_HOST=<planetscale-host>
DB_DATABASE=<name-or-@primary-for-sharded>
MYSQL_ATTR_SSL_CA=/opt/bref/ssl/cert.pem

Two PlanetScale-specific developer-experience items:

  • SSL is mandatory — PlanetScale terminates TLS at the edge; the PDO trust store path inside Lambda differs from the local-dev path (/opt/bref/ssl/cert.pem vs /etc/ssl/cert.pem). See concepts/ssl-handshake-as-per-request-tax.
  • Sharded keyspaces route via @primary — unsharded users pass the literal database name; sharded users pass @primary to opt into VTGate auto-routing to the correct shard. ("For DB_DATABASE, you can use your PlanetScale database name directly if you have a single unsharded keyspace. If you have a sharded keyspace, you'll need to use @primary.")

Benchmark against PlanetScale (baseline, shares-nothing PHP): p50 75 ms / p95 130 ms at 3,800 req/min, 180 QPS, 0.3 ms median PlanetScale query time. The PHP latency is dominated by per-request TLS handshake + Laravel bootstrap cost — see concepts/shared-nothing-php-request-model. Switching to Laravel Octane on Bref with persistent connections recovers 5.4× p50 (75 ms → 14 ms) by amortising handshake + bootstrap across BREF_LOOP_MAX = 250 invocations per Lambda execution context. See patterns/persistent-process-for-serverless-php-db-connections.

This pairs with the benchmark to give both sides of the serverless-database-connection story:

Both are composable; large-scale serverless-PHP deploys want both.

Seen in — TAOBench social-graph benchmark

  • — Liz van Dijk (PlanetScale Tech Solutions, 2022-09-08) introduces TAOBench (Audrey Cheng, UC Berkeley + Meta, VLDB 2022) as a social-graph-shaped complement to the 1M-QPS sysbench-tpcc sibling post for PlanetScale's 2022 benchmarking programme. The published run uses a 48-CPU-core resource cap (set by Cheng's team), allocated as 44 cores to the Vitess query path + 4 cores to multi-tenant serverless overhead (edge load balancers) — canonicalises concepts/constrained-resource-benchmark and patterns/constrained-resource-benchmark-for-shared-tenant-capability-disclosure. The key takeaway van Dijk names is graceful saturation — "sustained stability of PlanetScale clusters under even the most extreme resource pressure" — not peak throughput. Architectural reframing: the substrate property that matters is behaviour past 100% CPU, not the peak-QPS number. TAOBench's objects + edges schema (concepts/social-graph-objects-and-edges) explicitly stresses concepts/hot-row-problem + concepts/thundering-herd — the viral-content workload the benchmark is designed to simulate, distinct from sysbench-tpcc's shard-key-aligned workload with no hot rows by construction. The two benchmarks together span PlanetScale's 2022 Vitess capability disclosure: OLTP-shaped shard-linear scaling (sysbench-tpcc) + social-graph-shaped substrate-maturity-at-the-ceiling (TAOBench).
Last updated · 542 distilled / 1,571 read