Does MySQL Work in China? Data Residency, Localization & PIPL Cross-Border
MySQL is free, open-source software you self-host anywhere — including on mainland-China soil — so the engine is residency-neutral and never blocked. The real question is where you run it: an offshore or non-China-region managed MySQL leaves your China users' records offshore, a PIPL cross-border and data-localization exposure. A compliance-first look at MySQL and China data residency.
Does MySQL work in China?
MySQL is not blocked in China and runs fine — so the real question is a data-residency one: where the personal information it holds is allowed to come to rest.
MySQL is free, open-source software (GPL-licensed, owned by Oracle) that you download and run yourself, which makes the engine residency-neutral — you can self-host it on mainland-China soil, and that is the lawful lever. The exposure is the deployment: a managed MySQL in a global-cloud region (Amazon RDS and Aurora, Azure Database for MySQL, Google Cloud SQL) or any non-China region leaves your Chinese users' personal data offshore — a cross-border transfer PIPL governs on every read and write. For a critical information infrastructure operator or high-volume handler, that data must stay in the mainland (Cybersecurity Law Article 39, formerly Article 37; PIPL Article 40), which no offshore database can meet. In-country managed MySQL does exist, but only on separate sovereign clouds (AWS China via Sinnet and NWCD, Azure China via 21Vianet, Alibaba Cloud ApsaraDB) — an in-country region is not automatic compliance.
This is a risk map, not a verdict — your duties turn on your entity, your data volumes, and whose data you hold. Our China team can map your exposure →
What MySQL's own documentation says about China
| Fact | Primary source |
|---|---|
| MySQL is free, open-source software you run yourself — so the engine is residency-neutral, not blocked. In its own words, "MySQL Community Edition is the freely downloadable version of the world's most popular open source database," "available under the GPL license" and running on "over 20 platforms and operating systems including Linux, Unix, Mac and Windows." Because you download and install the server wherever you choose, you can self-host MySQL on mainland-China infrastructure — the lawful lever for keeping China data on Chinese soil. | MySQL Community Edition — mysql.com, retrieved 2026-10-10 |
Managed MySQL in the global clouds has no mainland-China region; the in-country options are separate sovereign clouds. Amazon RDS and Aurora MySQL-Compatible, Azure Database for MySQL, and Google Cloud SQL for MySQL deploy only to their providers' global regions — Google states "Cloud SQL is available in all Google Cloud regions," whose nearest Asia entries are Taiwan (asia-east1) and Hong Kong (asia-east2), none in mainland China. In-country, managed MySQL runs only on separate sovereign clouds with their own accounts: AWS China's aws-cn partition operated by Beijing Sinnet and Ningxia Western Cloud Data (NWCD), Azure China operated by 21Vianet, and Alibaba Cloud's ApsaraDB RDS for MySQL — each with its own ICP and compliance obligations. | Google Cloud SQL for MySQL — instance locations (cloud.google.com), retrieved 2026-10-10 |
| For a CIIO or high-volume handler, China-collected data must be stored in the mainland — a duty no offshore database meets. Personal information collected or generated in mainland China must be stored inside it (Cybersecurity Law Article 39 (formerly Article 37) — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged; and PIPL Article 40). A MySQL instance offshore, or in a non-China managed region, has no mainland copy to satisfy that in-country storage duty; self-hosting in-country, or a licensed sovereign managed MySQL, does. | Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40 |
| China users' personal data in an offshore MySQL is a cross-border transfer under PIPL. Where personal information collected from people in mainland China is stored or processed outside it, PIPL makes the handler — you, not Oracle or the cloud — responsible for giving notice, obtaining separate consent, and clearing one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (Articles 38–43). Every read and write from China to an offshore database repeats that transfer. | PIPL Articles 38–43 — cac.gov.cn, retrieved 2026-10-10 |
Sources verified by the 21YunBox compliance team on 2026-10-10.
For a mainland-China audience, the deciding question about MySQL is not whether it installs, connects, or returns a query — it does, everywhere — but where the data it holds is allowed to come to rest. MySQL is the system of record behind countless applications: customer records, user accounts, logins, orders and transactions, and the personal information wrapped up in all of them. MySQL is unusual on this list because it is free, open-source software you download and run yourself: the engine is residency-neutral, never blocked, and runs perfectly well on mainland-China soil. That is precisely the lawful lever. The compliance exposure is not the engine — it is where and how you deploy it. Run it on an offshore managed service, or in a cloud region outside China, and your Chinese users’ personal data lives on the wrong side of the border. Run it in-country and it does not.
asia-east1 (Taiwan) and asia-east2 (Hong Kong), with none in mainland China. The engine itself installs anywhere, including on mainland soil; it is the managed deployment that inherits an offshore-only region list. Source: cloud.google.com/sql/docs/mysql/locationsMySQL in China at a glance
| What decides it | In MySQL's own terms — and China's law |
|---|---|
| Where the data physically rests | MySQL stores data wherever you install the server. Self-host it and the data lives on that machine; use a managed MySQL and it lives in the region that service offers — and Google Cloud SQL for MySQL, for one, is “available in all Google Cloud regions,” none of which is in mainland China. |
| What MySQL holds | The system of record: customer records, user accounts, logins, orders and transactions. Almost all of it is personal information, so where the database sits is where that personal information sits. |
| Your China users' records | Held in an offshore region or a non-China managed service, your Chinese users' personal data rests outside the mainland — a cross-border transfer PIPL governs (Articles 38–40), carried across the border on every read and write. |
| The in-country storage duty | For a critical information infrastructure operator or a high-volume handler, personal information collected in China must stay in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). An offshore database cannot meet that duty. |
| Is it reachable? | Reachability is not the axis — MySQL is open-source software, not a blocked site. The lawful path is to run it in-country: self-hosted on mainland infrastructure or on a licensed sovereign-cloud option, with the China-facing surface on an ICP-filed footing. |
Where the data actually rests
MySQL itself has no home region — it runs on the machine you put it on, which is exactly why the engine is residency-neutral. The residency question lands entirely on your deployment. Download MySQL and run it on a server inside mainland China, and the data rests on Chinese soil. Point your application at a managed MySQL in a global cloud, and the data rests wherever that service offers a region.
That is where the managed landscape matters. In the global clouds — Amazon RDS and Aurora MySQL-Compatible, Azure Database for MySQL, Google Cloud SQL for MySQL — you pick from the provider’s regions, and none in the global partition sits inside mainland China. Google is explicit that “Cloud SQL is available in all Google Cloud regions,” and its nearest Asia regions are Taiwan (asia-east1) and Hong Kong (asia-east2) — close, reachable, and still outside the mainland for residency purposes; Google Cloud has no mainland region at all. A managed MySQL there holds your China data offshore.
In-country, managed MySQL does exist — but only on separate, sovereign clouds reached through their own accounts: AWS China is a distinct aws-cn partition operated by Beijing Sinnet (cn-north-1) and Ningxia Western Cloud Data, or NWCD (cn-northwest-1); Azure China is operated by 21Vianet; and Alibaba Cloud’s ApsaraDB RDS for MySQL runs in its mainland regions. These are real in-country options, but each is a different operator and account than the global service you may already use, with its own feature set, ICP filing, and compliance obligations — an in-country region is not automatic compliance.
What it holds is personal information
A database is where personal information physically comes to rest, which makes MySQL the most literal data-residency question you can ask. The rows in it are names, contact details, login credentials, order histories, payment references — personal information under China’s Personal Information Protection Law. Once that information is collected from people in China and stored in an offshore MySQL, holding it there is a cross-border transfer, and every query that reads or writes it moves personal data across the border again. PIPL puts the obligation on you — the handler, not Oracle or the cloud — to give notice, obtain separate consent, and clear one transfer mechanism: a CAC security assessment, the CAC standard contract, or certification (Articles 38–43).
For some handlers the law goes further than a transfer mechanism and requires the data to stay put. If you are a critical information infrastructure operator, or you process personal information above the regulated volume thresholds, personal information collected in the mainland must be stored in the mainland (Cybersecurity Law Article 39 (formerly Article 37) — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, substance unchanged; and PIPL Article 40). An offshore MySQL, or a managed instance in a non-China region, structurally cannot meet that in-country storage duty — there is no mainland copy of the data to point to.
Running it offshore doesn’t meet the residency duty — and what does
The fix for an offshore residency gap is not a faster connection back to the offshore database — moving the same personal data across the border more quickly leaves it just as offshore. The lawful lever is the one MySQL hands you for free: run the engine in-country. Because MySQL is open-source software with no home region, you can stand up a MySQL server on mainland infrastructure, or adopt a licensed sovereign-cloud managed MySQL, and keep your Chinese users’ personal information on Chinese soil — where the residency and localization duties are satisfied by design rather than worked around.
Doing that does not mean migrating off MySQL or rewriting your application: it is the same engine, the same SQL, the same schema, now resting in the right jurisdiction. What it takes is the in-country storage, the ICP filing for any public China-facing surface, and a lawful cross-border arrangement for whatever data genuinely has to move. This page is a risk map, not a verdict — whether you owe in-country storage, a transfer mechanism, or both turns on your entity, your data volumes, and whose personal information sits in the database, so settle the specifics with counsel before you build.
The lawful path — map, localize, deliver
You keep running MySQL. 21YunBox adds the piece an offshore or global-cloud database cannot: a lawful, in-country home for the data and an ICP-filed way to reach it.
- Map. Our China compliance team reads your PIPL cross-border, data-residency, and data-localization (CII) obligations, and your ICP obligations, against your entity, your data volumes, and whose personal information sits in your MySQL.
- Localize. We run MySQL in-country — self-hosted on mainland infrastructure, or on a licensed sovereign-cloud option — so your Chinese users’ personal information stays on mainland soil, with consented, in-country storage for what must stay. Localize means standing up a lawful in-country MySQL, not tunnelling back to an offshore endpoint.
- Deliver. Any China-facing surface in front of the database — the app, the API edge, the admin and reporting portals your mainland users hit — runs over ICP-filed, in-country delivery (the 21YunBox Optimizer), in front of the stack you already run, with no rebuild and no second codebase.
21YunBox is a compliant overlay, not a migration, and a partner to MySQL and your cloud, not a competitor to them. 21YunBox never uses or suggests circumvention of any kind. The result is MySQL that runs legally and compliantly for your users in China.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- China data export security assessment measures
- How to get an ICP filing for China
