Does PlanetScale Work in China? Data Residency, PIPL & Your Database
PlanetScale runs no database region inside mainland China — it stores your data in the AWS or GCP region you choose, all offshore — so the personal information your app keeps on Chinese users is a PIPL cross-border transfer with a data-localization question attached. A compliance-first look.
Does PlanetScale work in China?
Reachability is not the question for PlanetScale — residency is. PlanetScale stores your database only in the AWS or GCP region you choose, and it runs no region inside mainland China, so the personal data your app keeps there lives offshore. That is a data-localization and cross-border-transfer question, not a speed one.
PlanetScale says it plainly: "the infrastructure supporting user databases, backups, etc., is in the provider (AWS or GCP) and region where the database is created," and "if you create a database in a US-based region, all data, including customer data, is stored and processed in the US." Its region menu spans the US, Europe and parts of Asia-Pacific — Tokyo, Mumbai, Singapore, Sydney, Seoul — but nowhere in the mainland. So personal information your database collects from users in China leaves the country the moment it is written: a cross-border transfer PIPL governs (Articles 38–43), and for a CIIO or large-volume handler, data China law says must stay in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — which PlanetScale has no region to hold. The one door it does not put on you is ICP: a database serves no public site, so that filing belongs to the application in front of it. The table below is PlanetScale's own wording and the rule each line triggers.
This is a risk map, not a verdict — what you owe turns on your entity, your data volumes and whose personal information sits in the database. Our China team can map your exposure with you →
What PlanetScale's own documentation says about China
| Fact | Primary source |
|---|---|
| PlanetScale runs only in AWS and GCP regions outside mainland China. Its published region list spans the US, Europe and parts of Asia-Pacific — in AWS, Tokyo, Mumbai, Singapore and Sydney; in GCP, Seoul — and not one region sits inside mainland China. PlanetScale's own guidance is to "select the region closest to your application servers," but for a China audience the closest it offers is still offshore. | PlanetScale Docs — Regions (planetscale.com/docs/plans/regions), retrieved 2026-10-07 |
| Your data lives wherever you create the database — and PlanetScale offers nowhere in China to create it. PlanetScale states "the infrastructure supporting user databases, backups, etc., is in the provider (AWS or GCP) and region where the database is created," and that "if you create a database in a US-based region, all data, including customer data, is stored and processed in the US." The same rule binds a China-facing database to an offshore region, because no mainland region exists to choose. | PlanetScale Docs — Security & data residency (planetscale.com/docs/security), retrieved 2026-10-07 |
| The personal data your database holds on Chinese users is a cross-border transfer under PIPL. Because those records are stored outside the mainland, handling them is a cross-border transfer of personal information China's PIPL governs — notice, separate consent and one approved transfer mechanism (Articles 38–43). If you are a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a duty no offshore PlanetScale region can satisfy. | PlanetScale Docs — Security, retrieved 2026-10-07; PIPL Articles 38–43 & 40; Cybersecurity Law Article 39 (formerly Article 37) |
| PlanetScale's compliance weight is data residency, not ICP. A database serves no public website, so the ICP filing a mainland audience requires (State Council Order No. 292; MIIT Order No. 33) attaches to the application in front of your database, not to PlanetScale. What PlanetScale does decide is where the data sits: even its enterprise Managed tier keeps "the data stored in PlanetScale Managed databases ... contained entirely in the customer's AWS Organizations member account or GCP project" — your account, but still an AWS or GCP region, none in mainland China. | PlanetScale Docs — Managed: Cloud accounts and contents (planetscale.com/docs/plans/managed/security-and-access/cloud-accounts-and-contents), retrieved 2026-10-07; State Council Order No. 292; MIIT Order No. 33 |
Sources verified by the 21YunBox compliance team on 2026-10-07.
For a mainland-China audience, the question about PlanetScale is not whether the database responds — it is where the data inside it is allowed to live. PlanetScale is a managed MySQL platform built on Vitess, which means it holds your application’s real records, your Chinese users’ personal information among them. PlanetScale answers the residency question in its own documentation: every database runs in the AWS or GCP region you create it in, and it operates no region inside mainland China. The endpoint is reachable; the exposure is that the personal data it stores sits offshore, where China’s cross-border and data-localization rules reach it.
PlanetScale in China at a glance
| What decides it | In PlanetScale's own terms |
|---|---|
| Where it runs | AWS and GCP regions across the US, Europe and Asia-Pacific. The nearest to China are Tokyo, Mumbai, Singapore and Sydney (AWS) and Seoul (GCP) — all offshore. No region is inside mainland China. |
| Where your data physically sits | “The infrastructure supporting user databases, backups, etc., is in the provider (AWS or GCP) and region where the database is created.” You pick the region; PlanetScale offers none in the mainland. |
| Your China users' data | Stored in the offshore region you chose — a cross-border transfer of personal information PIPL governs (Articles 38–43), on infrastructure that keeps it out of the country it was collected in. |
| Data localization | A CIIO or large-volume handler must keep China-collected personal data in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). PlanetScale has no in-China region to satisfy it. |
| ICP filing | Not PlanetScale's door. A database serves no public site, so the ICP filing a mainland audience needs sits on the application in front of your database, not on PlanetScale. |
No mainland region, so your data cannot sit in China
PlanetScale runs your database on Amazon Web Services and Google Cloud, in the region you choose at creation. Its published region list reaches across the US, Europe and parts of Asia-Pacific — in AWS, Tokyo, Mumbai, Singapore and Sydney; in GCP, Seoul — and while PlanetScale’s regions have shifted over time, mainland China has never been among them. PlanetScale is explicit about what that means for your data: “the infrastructure supporting user databases, backups, etc., is in the provider (AWS or GCP) and region where the database is created,” and “if you create a database in a US-based region, all data, including customer data, is stored and processed in the US.” Pick any region PlanetScale offers for a China-facing app and the same rule binds your users’ records to a place outside the mainland. This is the data-residency question in its purest form: the database is not a cache or an edge sitting in front of your data — it is your data, and PlanetScale has nowhere in China to keep it.
Your China users’ personal data is a cross-border transfer
Because that database holds personal information collected from people in China, storing it offshore is a cross-border transfer under the Personal Information Protection Law. The handler — you, not PlanetScale — has to give notice, obtain separate consent, and clear one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (PIPL Articles 38–43). And if you are a critical information infrastructure operator, or you process personal information above the regulators’ volume thresholds, that data must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a residency duty an offshore AWS or GCP region cannot meet. Even PlanetScale’s enterprise Managed tier, which keeps “the data stored in PlanetScale Managed databases … contained entirely in the customer’s AWS Organizations member account or GCP project,” only moves the account under your control; the region menu is still AWS and GCP, with no mainland option.
ICP isn’t PlanetScale’s door — and naming that honestly matters
It would be easy to bolt an ICP-filing warning onto every China page, but it does not belong on PlanetScale. An ICP filing (ICP 备案) under State Council Order No. 292 and MIIT Order No. 33 attaches to a public-facing website and the mainland hosting that serves it — and a database serves no public site of its own. So that obligation sits on the application in front of your PlanetScale database, if that application faces a Chinese audience, not on the database layer itself. PlanetScale’s compliance weight is narrower and heavier in one spot: data residency. Keeping the two doors distinct is the point — it tells you precisely which risk lives where, instead of blurring a storage question into a licensing one.
This is a risk map, not a verdict: whether a localization duty applies, and which cross-border mechanism fits, depends on your entity, how much personal data you hold, and whose it is — worth settling with counsel before you build.
Where 21YunBox fits — a compliant overlay, not a migration
You keep PlanetScale as your database. We add the layer it was never built to provide: compliant, ICP-filed delivery from inside the mainland for the application in front of it, together with any in-China storage your data-residency obligations require — set up around your existing stack, with no rebuild, no second codebase, and no move off PlanetScale. Our China team maps your PIPL cross-border and data-localization exposure against your entity and data volumes, then stands up the in-country delivery and storage a lawful China presence needs, while your database stays exactly where it already runs.
Related reading:
