Does Databricks Work in China? Region Availability, Data Residency & Cross-Border Transfer
On Databricks' own global commercial clouds — AWS, Azure, and Google Cloud — there is no mainland-China workspace region, so a Databricks workspace serving China is normally hosted offshore. The real decision isn't speed: loading mainland-collected data into an offshore lakehouse is a PIPL cross-border transfer, moving important data out can require a CAC data-export security assessment, and a critical information infrastructure operator faces an in-country storage duty (Cybersecurity Law Article 39, formerly Article 37) that no offshore region can meet. A compliance-first look at region availability, data residency, the cross-border question, and the lawful in-country path.
Does Databricks work in China?
On Databricks' own global commercial clouds — AWS, Microsoft Azure, and Google Cloud — there is no mainland-China workspace region, so a Databricks workspace serving China is normally hosted offshore. The nearest supported regions are Tokyo, Seoul, Singapore, Sydney, Mumbai, and Jakarta; none is in the mainland.
For a China-facing product the decision is therefore a data-residency one, not a speed one. Loading mainland-collected personal information into an offshore workspace is a PIPL cross-border transfer (Articles 38–40: notice, a separate consent, and a transfer mechanism); moving “important data” out can require a CAC data-export security assessment; and a critical information infrastructure operator must store China-collected personal information in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a duty no offshore region can meet. One in-country footing exists: Azure Databricks on the separate, 21Vianet-operated (世纪互联) Azure China cloud, which you confirm directly with Microsoft and 21Vianet.
21YunBox maps your data-residency exposure, localizes your China data in-country, and delivers the China-facing app on ICP-filed infrastructure — not a route to an offshore Databricks region from the mainland, and never through circumvention. Treat the specifics as a risk to confirm with counsel.
What Databricks's own documentation says about China
| Fact | Primary source |
|---|---|
| Databricks runs only on the three global commercial clouds. Databricks' documentation states: “Databricks workspaces can be hosted on Amazon AWS, Microsoft Azure, and Google Cloud Platform.” Databricks operates no datacenters of its own; a workspace lives in a cloud region you choose. | Databricks Documentation, “Databricks clouds and regions” (docs.databricks.com), retrieved 2026-10-08 |
| No supported workspace region is in mainland China. Databricks' supported AWS regions run across the Americas, Europe, and Asia Pacific — the nearest to China being Tokyo, Seoul, Singapore, Sydney, Mumbai, and Jakarta — with no mainland-China region; its Google Cloud region list is the same. | Databricks Documentation, “Supported AWS regions” / “Supported GCP regions” (docs.databricks.com), retrieved 2026-10-08 |
| The one in-country footing is a separate, locally operated cloud. Azure Databricks is offered on Microsoft Azure operated by 21Vianet (世纪互联) — a network-isolated China cloud run by a licensed local operator — whose documentation lists China East and China North regions. Availability and compliance there are to confirm directly with Microsoft and 21Vianet. | Microsoft Azure operated by 21Vianet — Azure Databricks “supported regions” (docs.azure.cn), retrieved 2026-10-08 |
| Mainland data in an offshore workspace is governed by China's data-export rules. Sending China-collected personal information to a workspace hosted offshore triggers PIPL Articles 38–40 (notice, a separate consent, and a transfer mechanism); a critical information infrastructure operator also faces an in-country storage duty (PIPL Article 40; Cybersecurity Law Article 39, formerly Article 37). | Personal Information Protection Law of the PRC, Articles 38–40 (cac.gov.cn), retrieved 2026-10-08 |
Sources verified by the 21YunBox compliance team on 2026-10-08.
For a mainland-China audience, the first thing to settle about Databricks is not how quickly a query returns — it is where the data lives. Databricks is a lakehouse platform for data engineering, warehousing, analytics, and AI, and it runs no datacenters of its own: a Databricks workspace is deployed inside your own account on Amazon AWS, Microsoft Azure, or Google Cloud. On Databricks’ own global commercial clouds, none of the supported workspace regions is in mainland China — the nearest sit in Tokyo, Seoul, Singapore, Sydney, Mumbai, and Jakarta. So unless you take a specific in-country path, a Databricks workspace serving a China-facing product is hosted offshore, and every row you load into it from the mainland crosses the border.
That makes “does it load from Beijing?” the wrong question. A lakehouse is built to gather personal information, transaction records, device logs, and business data into one place — exactly the categories China’s data laws govern most tightly. Whether a request completes quickly is beside the point; what decides it is whether mainland-collected data had a lawful basis to leave the country at all, and whether your role carries an in-country storage duty that an offshore region cannot meet. For that reason this page publishes no first-party China latency figure for Databricks: for a data platform, speed is downstream of residency. And to be unambiguous — there is no lawful way around China’s data-export rules, and 21YunBox neither provides nor suggests circumvention of any kind.
Databricks in China at a glance
| What decides it | In Databricks' own terms — and China's law |
|---|---|
| What it is | A lakehouse platform — data engineering, warehousing, analytics, and ML/AI — that runs inside your own AWS, Azure, or Google Cloud account. Databricks operates no datacenters of its own; your workspace lives in a cloud region you choose. |
| Is there a mainland-China region? | On Databricks' global commercial clouds (AWS, Azure global, Google Cloud), no — the supported regions are all offshore (nearest: Tokyo, Seoul, Singapore, Sydney, Mumbai, Jakarta). The one in-country footing is Azure Databricks on the separate, 21Vianet-operated (世纪互联) Azure China cloud, run by a licensed local operator — availability and compliance to confirm directly with Microsoft and 21Vianet. |
| Loading mainland data into an offshore workspace | A cross-border transfer of personal information under PIPL (Articles 38–40): notice, a separate consent, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. The handler's duty is yours, not the cloud provider's. |
| Important data & in-country storage | Moving “important data” out of China can require a CAC data-export security assessment regardless of personal-information volume. A critical information infrastructure operator must store personal information collected in China inside the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — a duty no offshore region can satisfy. |
| The lawful path | Keep mainland data in-country — on an in-country analytics footing (the 21Vianet-operated sovereign cloud where available, or a domestic lakehouse/warehouse) — and deliver the China-facing app or dashboard on ICP-filed, in-country infrastructure. 21YunBox maps the residency exposure, localizes the China data, and delivers the app — it is not a route to an offshore Databricks region from the mainland. |
Region availability: no mainland-China region on Databricks’ global clouds
Databricks does not run its own infrastructure; a workspace is deployed into your own account on one of three global commercial clouds. Databricks’ documentation is explicit about which: “Databricks workspaces can be hosted on Amazon AWS, Microsoft Azure, and Google Cloud Platform.” Its supported-region tables for those clouds run across the Americas, Europe, and Asia Pacific — on AWS the nearest to China are Tokyo, Seoul, Singapore, Sydney, Mumbai, and Jakarta — and none of them is in mainland China. Google Cloud is the same. So a Databricks workspace built the ordinary way to serve a China-facing product is hosted outside the mainland, and the data it holds lives offshore.
There is one in-country exception, and it is worth stating precisely because it is a lawful option, not a loophole. Microsoft Azure in the mainland is a separate, network-isolated cloud — Microsoft Azure operated by 21Vianet (世纪互联) — run by a licensed local operator whose datacenters keep data inside China, and Azure Databricks is offered on it. Whether a given Databricks capability is available in that cloud at a given time, and on what compliance terms, is something you confirm directly with Microsoft and 21Vianet rather than assume from the global service. That footing is exactly the kind of in-country option onto which a China-facing analytics workload can be localized.
This is why the usual “does it load fast from Shanghai?” framing misses the point. A workspace that answers quickly but is hosted offshore has not answered the question that actually governs it — whether the mainland data inside it was lawfully allowed to be there. Speed is real, but for a data platform it sits downstream of residency.
The data-residency question: mainland data in an offshore workspace
Load a single table of mainland-collected user records into a Databricks workspace in an offshore region and you have moved personal information out of China. Under China’s Personal Information Protection Law that is a cross-border transfer, and the obligation falls on the handler — you, not Databricks or the cloud provider: Articles 38–40 require notice, a separate consent distinct from any general terms, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. A lakehouse makes this heavier, not lighter, because its whole purpose is to concentrate data: customer profiles, order histories, device and app telemetry, and the derived tables built on top of them all land in one place, and all of it crosses the border on ingest.
Underneath that sits a residency duty. For a critical information infrastructure operator, and for a large-volume handler, personal information collected in China must be stored inside the mainland — PIPL Article 40, read with Cybersecurity Law Article 39 (formerly Article 37). An offshore Databricks region structurally cannot satisfy that: the storage is, by definition, outside China. How heavy the duty is depends on your volumes and your role, which is why it belongs with counsel rather than with a default assumption — treat the specifics as a risk to confirm with counsel against what you actually process.
”Important data,” not just personal information
Personal information is only half of it. China’s data-export regime also governs “important data,” and a lakehouse is precisely where important data accumulates — aggregated behavioral, geographic, operational, and industry datasets that are unremarkable row by row but regulated in bulk. Moving important data out of the mainland can require a CAC data-export security assessment regardless of how much personal information is involved, and the assessment turns on what the data is and where it goes, not on how quickly a cluster can scan it. Whether any dataset you hold counts as “important data” for your sector is itself a determination to make with counsel; the point for a Databricks deployment is that the question is triggered by the architecture — centralizing mainland data in an offshore workspace — not by any performance setting.
The lawful shape — and where 21YunBox fits (map, localize, deliver)
There is a lawful shape for running Databricks-style analytics for a China audience, and it starts from residency rather than from a region menu. Keep mainland-collected data in the mainland, and give the China-facing app or dashboard that sits on top of it a compliant, in-country home. That is the part 21YunBox owns, and it is more than advice.
Our China team does three things on that footing. We map your data-residency and cross-border exposure — which datasets are personal information, which may be “important data,” whether your role carries the Article 40 / Article 39 (formerly Article 37) storage duty, and which PIPL transfer mechanism, if any, your flows need. We localize the China side in-country — keeping mainland data on an in-country analytics footing (the 21Vianet-operated sovereign cloud where the service is available, or a domestic lakehouse or warehouse) instead of letting it default into an offshore workspace. And we deliver the China-facing product in-country: the dashboard, portal, or app that surfaces the analytics is itself a public service in the mainland, so it carries an ICP filing (备案) duty and needs compliant, in-country delivery through the 21YunBox Optimizer — in front of the stack you already run, with no rebuild and no re-platform.
What we do not do, and what no one lawfully can, is give you a way to feed mainland data into an offshore Databricks region as if the border were not there. We map the exposure, localize the data in-country, and deliver the app — so your China analytics, and the product on top of them, run on a lawful footing. The specifics are a risk to confirm with counsel against what you actually ship.
Related reading:
- China’s data-export security assessment measures
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law — in-country storage, Article 39 (formerly Article 37)
