Does TiDB Work in China? Data Residency, ICP & Cross-Border Rules
TiDB is an open-source, self-hostable distributed SQL database, so the engine runs anywhere — including on mainland-China infrastructure. The real question is residency: a TiDB cluster holds the personal information and business records your app stores at rest, so an offshore managed cluster is a PIPL cross-border transfer, and at scale an in-country storage duty under Cybersecurity Law Article 39 (formerly Article 37).
Does TiDB work in China?
TiDB runs in China — the question is not whether it connects, but where the data it holds is allowed to rest. A TiDB cluster stores the personal information and business records your application collects, and if that data sits in an offshore managed region it is a cross-border transfer PIPL governs. TiDB is open-source and self-hostable, so the lawful fix is not a route back offshore — it is running the cluster in-country, where the regulated data stays resident.
TiDB Cloud is a fully managed Database-as-a-Service PingCAP offers on AWS, Azure, Google Cloud, and Alibaba Cloud; its published international regions sit offshore and we found no confirmed mainland-China region, so a managed cluster of your China users' records can come to rest outside the mainland — a cross-border transfer under PIPL (Articles 38–40), and for a critical information infrastructure operator or a large-volume handler an in-country storage duty (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) an offshore region cannot meet. Because the engine is Apache-2.0 open source, the lawful path is to self-host it on mainland infrastructure so the data stays resident.
This is a risk map, not a verdict — whether a localization duty binds you, and which cross-border mechanism fits, turns on your entity, your data volumes, and whose data it is. Our China team can map your data-residency exposure with you →
What TiDB's own documentation says about China
| Fact | Primary source |
|---|---|
| TiDB is open-source (Apache 2.0) and self-hostable on infrastructure you control. PingCAP's TiDB Self-Managed page says you can “Deploy and manage TiDB on your own infrastructure with complete flexibility” and “Run TiDB in your own VPC, data center, or Kubernetes cluster with full control over networking, access, and compliance,” and the engine is licensed Apache 2.0 in its public repository. So the engine is residency-neutral: you can run the same TiDB cluster on mainland-China infrastructure, and that self-hosted path is the lawful lever for keeping China-collected data resident. | PingCAP — TiDB Self-Managed (pingcap.com); Apache License 2.0, pingcap/tidb repository (github.com); retrieved 2026-10-12 |
| TiDB Cloud is a managed DBaaS on offshore clouds — no confirmed mainland-China region. PingCAP's documentation calls TiDB Cloud “a fully managed, cloud-native Database-as-a-Service (DBaaS)” that “is currently available on AWS, Azure, Google Cloud, and Alibaba Cloud.” The published international regions we could confirm — Singapore, Tokyo, Jakarta and others — sit outside the mainland, and we found no confirmed mainland-China region for the managed service; confirm current region options with PingCAP, because a managed cluster placed in an offshore region stores your China users' records offshore. | PingCAP — What is TiDB Cloud (docs.pingcap.com), retrieved 2026-10-12 |
| China-collected personal data stored offshore is a cross-border transfer under PIPL. Because a TiDB cluster holds the personal information your application collects from people in China, storing it in an offshore region is a cross-border transfer under PIPL (Articles 38–40): you must give notice, obtain a separate consent, and clear one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. Reachability from Shanghai does not change this; the data is stored abroad. | Personal Information Protection Law, Articles 38–40; retrieved 2026-10-12 |
| For a CIIO or large-volume handler, the data must be stored in the mainland. Under PIPL Article 40 and the Cybersecurity Law Article 39 (formerly Article 37), personal information and important data collected in the mainland by a critical information infrastructure operator — or, at the volumes the CAC specifies, a large-volume handler — must be stored in-country. The 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39 with the substance unchanged. An offshore TiDB Cloud region structurally cannot meet this; self-hosted TiDB in-country can. | Cybersecurity Law Article 39 (formerly Article 37); PIPL Article 40; retrieved 2026-10-12 |
Sources verified by the 21YunBox compliance team on 2026-10-12.
For a product that serves mainland China, the first question about TiDB is not whether it installs or whether your application can reach it — it can; TiDB is open-source software that runs wherever you deploy it. The question is where the data it holds is allowed to come to rest. TiDB, built by PingCAP, is a distributed SQL database that stores a system’s transactional records at rest — accounts, orders, profiles, identifiers, and the business records your application writes — frequently making a TiDB cluster one of the largest single concentrations of personal information a company holds about its China users. Two facts fix the compliance posture. The engine itself is Apache-2.0 open source and residency-neutral — self-hostable on mainland-China infrastructure, which is the lawful lever. The managed service, TiDB Cloud, is a fully managed Database-as-a-Service that PingCAP offers on AWS, Azure, Google Cloud, and Alibaba Cloud; whether any region you can actually select places your data inside the mainland is something to confirm with PingCAP, because the published international regions rest offshore.
TiDB in China at a glance
| What decides it | In TiDB's own terms — and China's law |
|---|---|
| Where does the data physically rest? | TiDB Cloud is a fully managed service PingCAP runs on AWS, Azure, Google Cloud, and Alibaba Cloud, and its published international regions — such as Singapore, Tokyo, and Jakarta — sit outside the mainland. We found no confirmed mainland-China region for the managed service, so a managed cluster placed in those regions rests offshore; confirm the current region options with PingCAP directly. The engine, by contrast, is Apache-2.0 open source and runs wherever you install it, including self-hosted on mainland-China infrastructure. |
| What a TiDB cluster holds — and why it's personal information | TiDB is a distributed SQL database for a system's primary records: user accounts, orders, transactions, profiles, and the data your application writes and reads. That routinely includes names, phone numbers, email and account identifiers, addresses, and transaction histories — personal information under the Personal Information Protection Law, and sensitive personal information under PIPL Article 28 where financial, health, precise-location, or minors' data appear. The point is the data is stored, at rest, in the cluster. |
| Your China users' records = a cross-border transfer if offshore | Storing personal information collected from users in mainland China in a cluster hosted in an offshore region is a cross-border transfer (数据出境) under PIPL Articles 38–40: notice, a separate consent, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. |
| The in-country storage duty | For a critical information infrastructure operator — and, at the volumes the Cyberspace Administration of China specifies, a large-volume handler — personal information collected in the mainland must be stored in the mainland under PIPL Article 40 and the 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). An offshore managed region structurally cannot meet it. |
| Reachability isn't the axis — the lawful path | That a cluster answers quickly changes nothing: the data still rests wherever the cluster runs, and the residency duty still applies. Because the engine is residency-neutral and self-hostable, the lawful path is to run it in-country — self-hosted on mainland infrastructure — and to put any China-facing surface in front of it on ICP-filed delivery. |
Where the data actually rests
TiDB’s position is set by where the cluster runs, not by a load-time test. The engine is free, Apache-2.0 open-source software, and PingCAP’s own TiDB Self-Managed page is explicit that you deploy and manage it on infrastructure you control: “Deploy and manage TiDB on your own infrastructure with complete flexibility,” and “Run TiDB in your own VPC, data center, or Kubernetes cluster with full control over networking, access, and compliance.” That is the lever — the same engine runs identically whether it sits offshore or on mainland-China soil, so residency is entirely a question of where you deploy it, not of whether the software works.
The managed service is a different map. TiDB Cloud is described in PingCAP’s own documentation as “a fully managed, cloud-native Database-as-a-Service (DBaaS),” and it “is currently available on AWS, Azure, Google Cloud, and Alibaba Cloud.” The published international regions we could confirm — Singapore, Tokyo, Jakarta, and others — sit outside the mainland, and we found no confirmed mainland-China region for the managed service; because that list can change, confirm the current options with PingCAP before relying on either answer. Where a managed cluster is placed in an offshore region, the personal information in it is stored offshore relative to the mainland, and moving mainland-collected personal information into it is a cross-border transfer out of China. Because of all this, the familiar “does it respond from Shanghai?” test is the wrong question — which is why this page publishes no first-party China latency figure for TiDB; speed is not the axis for data that is sitting in the wrong country. See our explainer on cross-border data transfers under PIPL.
What it holds is personal information
A TiDB cluster is rarely a handful of rows. TiDB is a distributed SQL database built to be the system of record for applications at scale — it holds the accounts, orders, payments, profiles, and transactional history your application writes and reads. That is precisely the data that identifies people: names, phone numbers, email and account identifiers, shipping and billing addresses, order and payment records, and the behavioral history attached to an account are personal information under China’s Personal Information Protection Law wherever they relate to an identified or identifiable person, and sensitive personal information under PIPL Article 28 where financial, health, precise-location, or minors’ data appear.
The scale sharpens the China question. A handler that processes personal information at the volumes the Cyberspace Administration of China specifies falls under heightened duties — a transfer mechanism before personal information may leave the country, and, for a critical information infrastructure operator or a handler holding data at those volumes, an in-country storage duty. Under PIPL Article 40 and the Cybersecurity Law Article 39 (formerly Article 37), personal information and important data collected in the mainland must be stored in the mainland. An offshore TiDB Cloud region structurally cannot satisfy that duty, and the larger your cluster, the more likely you are to be inside the threshold that triggers it.
Running it offshore doesn’t meet the residency duty — and what does
If a managed cluster in an offshore region cannot hold mainland-collected personal information that the law requires to stay home, the fix is not to reach back to that offshore endpoint from inside China — it is to run TiDB where the data must live. This is where TiDB’s open-source nature is decisive, and it is good news: because the engine is residency-neutral and self-hostable, you do not have to migrate off TiDB or rebuild your data layer to become compliant. You run the same engine, in-country.
The lawful in-country pattern is to self-host open-source TiDB on mainland-China infrastructure, so the cluster and the personal information in it never leave the country; TiDB’s distributed design — stateless SQL nodes over a replicated storage tier — is built to be deployed and scaled on your own bare metal, VMs, or Kubernetes, which is routine operation, not a re-platforming. Where a licensed in-country or sovereign-cloud managed option is available on the mainland, that is an alternative you confirm with the operator directly, subject to its own availability and compliance. In either case you transfer offshore only the aggregated or de-identified results that may lawfully leave, and you keep the raw, user-level China data in-country. None of this is a verdict on your specific situation: whether you are a critical information infrastructure operator, which volume thresholds you cross, which transfer mechanism applies, and whether any transfer is lawful at all are questions to settle with your counsel against the data you actually hold and the entity that holds it.
The lawful path — map, localize, deliver
There is a lawful, durable way to run TiDB for users in China, and it keeps the shape of your stack intact. 21YunBox is a compliant overlay, not a migration — and a partner to TiDB and PingCAP, not a competitor. Our China team works in three moves. We map your exposure: the PIPL cross-border question, the transfer mechanism, the in-country storage duty for critical information infrastructure operators and large-volume handlers, and the ICP filing (备案) obligation on any China-facing surface — read against your entity, your data volumes, and whose personal information sits in the cluster. We localize the database by running it in-country — self-hosted open-source TiDB on mainland infrastructure, or a licensed in-country option where one is available — so the personal information stays on mainland soil; localize means standing up a lawful in-country cluster, never a route back to an offshore endpoint. And we deliver every China-facing surface in front of the database — the application, the API edge, the admin and reporting portals your mainland users reach — in-country over ICP-filed infrastructure, the 21YunBox Optimizer, in front of the stack you already run, with no rebuild and no second codebase. The result runs legally and compliantly for your users in China. 21YunBox never uses or suggests circumvention of any kind.
Related reading:
- China’s Personal Information Protection Law (PIPL)
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
