Does dbt Work in China? Data Residency, ICP & Cross-Border Rules
dbt is the transformation layer — it runs SQL inside your data warehouse, so the China question is where that warehouse and the dbt run sit, not whether it opens from Shanghai. dbt's engine is open source and self-hostable (keep it in-country); dbt Cloud is the SaaS, with no mainland-China region — a PIPL cross-border and data-residency matter, not reachability.
Does dbt work in China?
Yes — dbt runs from mainland China, but that is not the question. dbt is the transformation layer: it executes SQL inside your data warehouse, so the compliance axis is where that warehouse — and the dbt run against it — sit, not whether the tool opens from Shanghai.
dbt's engine is open source and self-hostable (the Apache-2.0 build), which is the lever: run it in-country against an in-country warehouse and your China-origin data and its transformation stay resident. dbt Cloud, the hosted SaaS, lists no mainland-China region and keeps your project, run logs, artifacts and metadata offshore — metadata that maps your data's structure. Landing China-origin personal data offshore, or storing it there as a critical information infrastructure operator or high-volume handler, is a cross-border and data-residency question under PIPL (Articles 38–40) and the Cybersecurity Law's Article 39 (formerly Article 37) — not a reachability one.
This is a risk map, not a verdict — which duties bite turns on your entity, your role, your data volumes, and what your warehouse and models actually hold. Our China team can map your exposure with you →
What dbt's own documentation says about China
| Fact | Primary source |
|---|---|
dbt's engine is open source and self-hosted — you install and run it in your own environment. dbt Labs' own dbt-core repository states that “The source code in this repository is available to everyone under the standard Apache 2.0 license,” and dbt's docs have you install the open-source build yourself (python -m pip install dbt-oss) and run it from your own command line against your own data warehouse. Because the engine runs where you put it, you can run it on in-country infrastructure against an in-country warehouse and keep your China-origin data and its transformation resident rather than crossing the border. | dbt Labs — dbt-core repository (github.com/dbt-labs/dbt-core) & dbt docs 'Install dbt' (docs.getdbt.com), retrieved 2026-10-12 |
| dbt Cloud, the hosted SaaS, lists 11 hosted regions — none in mainland China. dbt's “Regions & IP addresses” documentation lists hosted regions across North America (US), EMEA (Frankfurt, London, Ireland), Australia (Sydney, Australia East) and Japan (Tokyo) on AWS, GCP and Azure, with each dbt account tied to a single region; no region is in mainland China. Run on dbt Cloud, your project, run metadata, logs and artifacts rest in one of those offshore regions — so for China-origin data the hosted tenant cannot meet an in-country storage duty. | dbt docs — 'Regions & IP addresses' (docs.getdbt.com), retrieved 2026-10-12 |
| Moving China-origin personal information offshore is a cross-border transfer under PIPL. Landing personal information collected in mainland China in an offshore warehouse — or holding the project, logs and metadata that describe it on an offshore tenant — is a cross-border transfer (数据出境) governed by PIPL Articles 38–40: it requires notice, a lawful transfer mechanism (a CAC security assessment, the CAC standard contract, or certification), and for sensitive personal information (government IDs, financial or health data in your tables or fixtures) a separate consent under PIPL Articles 28–29. | Personal Information Protection Law (PIPL), Articles 38–40 & 28–29 — 21YunBox gov-doc translation, retrieved 2026-10-12 |
| For a CIIO or high-volume handler, China-collected data must be stored in-country. Under the Cybersecurity Law's Article 39 (formerly Article 37) — the 2025 amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39 with its substance unchanged — a critical information infrastructure operator (and, with PIPL Article 40, a large-volume handler) must store personal information and important data generated in China inside the mainland, with a security assessment before any export. An offshore dbt Cloud tenant with no mainland-China region structurally cannot meet that duty; a self-hosted dbt run against an in-country warehouse can. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37) — 21YunBox gov-doc translation, retrieved 2026-10-12 |
Sources verified by the 21YunBox compliance team on 2026-10-12.
For a data team serving mainland China, the first thing to settle about dbt is that the question is not whether the dbt command runs from Shanghai, or whether a dashboard built on dbt’s models paints quickly. dbt is the transformation layer of your stack — the “T” in ELT. It does not host your data; it compiles and executes SQL transformations inside the data warehouse where your data already lives, pushing the compute down to the warehouse. That single fact reframes the China question. Because the work happens in the warehouse, the compliance axis is where that warehouse — and the dbt run against it — sit, and what dbt’s own by-products (its run logs, artifacts and metadata) describe about your data. dbt comes in two shapes that place those by-products very differently: dbt Core, the open-source engine you install and run in your own environment, and dbt Cloud, the SaaS that dbt Labs hosts in a fixed set of offshore regions.
dbt in China at a glance
| What decides it | In dbt's own terms — and China's law |
|---|---|
| What dbt is — the transformation ("T") layer | dbt compiles and runs SQL transformations inside the data warehouse where your data already sits; it pushes compute down to the warehouse rather than hosting the data itself. It comes in two shapes: dbt Core — the open-source engine you install and run in your own environment (dbt's current open-source build is distributed as dbt OSS under the Apache-2.0 license) — and dbt Cloud, the SaaS that dbt Labs hosts. |
| Residency follows the warehouse — and the control plane | Because transformations execute in the warehouse, where that warehouse sits decides where your data is processed and stored. dbt does not need to carry the rows out to transform them. But on dbt Cloud the control plane is offshore: your project, run metadata, logs and artifacts rest in dbt's hosted region — and dbt lists no region in mainland China. |
| The distinctive second half — metadata and logs | The half a reachability check never sees. dbt's artifacts — the manifest, catalog, run results and logs — are a structural map of your data: schemas, table and column names, compiled SQL, lineage, and (depending on your test and logging configuration) sample rows from failing tests. Held on an offshore dbt Cloud tenant, that map of your data — and anything logged with it — rests abroad every run. |
| Residency & cross-border | Landing personal information collected in China in an offshore warehouse, or holding the project and metadata that describe it on an offshore tenant, 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). Where tables or test fixtures carry government IDs, financial or health data, that content can be sensitive personal information under PIPL Articles 28–29. |
| Localization & the ICP door | For a critical information infrastructure operator or high-volume handler, Cybersecurity Law Article 39 (formerly Article 37) requires China-collected personal information to be stored in the mainland — which an offshore dbt Cloud tenant cannot satisfy. And any public, China-facing surface you stand up on dbt's outputs — a dashboard, data app or docs — is an internet information service carrying an ICP filing (备案) duty bound to mainland hosting. |
| Reachability is not the axis | Whether the `dbt` command answers from the mainland is operational, not the compliance question. What decides it is where the warehouse, the dbt run and its metadata live. Because dbt's engine is self-hosted, there is a lawful lever: run dbt in-country against an in-country warehouse so the data and its transformation stay resident, and deliver any China-facing surface compliantly — the 21YunBox Optimizer — in front of what you already run. |
What dbt actually is — the transformation layer, and what its metadata exposes
dbt is not a data store and not a website; it is the working engine that turns raw tables into the models your analytics depend on. It reads your SQL, compiles it, and runs it inside your data warehouse — Snowflake, BigQuery, Databricks, Redshift, Postgres, or another destination — so the heavy lifting happens where the data already resides. dbt’s open-source engine has long been known as dbt Core; dbt’s current open-source build is distributed as dbt OSS under the same Apache-2.0 license. Either way, it is software you install and run yourself, from your own environment, against a warehouse you choose.
That design is exactly why the China question is a residency question. dbt does not have to copy your rows out of the warehouse to transform them, so the single most important fact is where the warehouse sits. But dbt also produces a second, quieter asset that travels: its metadata. Every run emits artifacts — a manifest of your project, a catalog of schemas and columns, run results, and logs — that together form a precise structural map of your data: what tables exist, how they are named and joined, the compiled SQL that shapes them, and, depending on how your tests and logging are configured, sample values from the rows that fail a test. On dbt Core that map stays wherever you run it. On dbt Cloud it lives in dbt’s hosted region, alongside your project and run history — and dbt lists no region inside mainland China.
Wherever your models touch customer, user or employee tables, the data they transform is personal information under China’s Personal Information Protection Law, and where it includes government IDs, financial or health records it may be sensitive personal information. Whether that data — and the metadata that describes it — lives in the mainland or offshore is decided by which dbt you run and where you run it.
The doors: residency, cross-border, sensitive PI and ICP
Point dbt at an offshore warehouse, or run it on an offshore dbt Cloud tenant, and the first door opens. Personal information collected in China that lands in that offshore destination — and the project, logs and metadata dbt keeps about it — comes to rest abroad, which makes it a cross-border transfer (数据出境). The duty lands on you, the handler, not on dbt Labs: PIPL Articles 13 and 23 require notice and a basis to collect the data, and Articles 38–40 require a transfer mechanism to send it offshore — a CAC security assessment, the CAC standard contract, or certification — with a separate consent for the overseas transfer.
For some handlers, storage is not a matter of mechanism at all — it must stay in-country. If your organization operates critical information infrastructure, or handles personal information at scale, the Cybersecurity Law’s Article 39 (formerly Article 37 — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, its substance unchanged) requires personal information and important data generated in China to be stored in the mainland, with a security assessment before any export. An offshore warehouse, or an offshore dbt Cloud tenant with no mainland-China region, structurally cannot meet that duty.
A quieter, sharper door is the sensitivity of the data your models move through. Where the tables, seeds or test fixtures carry real government IDs, financial records or health data, that content can be sensitive personal information under PIPL Articles 28–29, which demand a specific purpose, heightened necessity and separate consent. And a third door follows from publishing: the moment you expose a public, China-facing surface built on dbt’s outputs — a BI dashboard, a data application, or the hosted dbt docs site your mainland users reach — that surface is an internet information service and carries an ICP filing (备案) duty bound to a mainland hosting resource.
Why a reachability check misses this
A probe from inside China can watch a dbt-powered dashboard load, or confirm that dbt run completes from a mainland machine, and conclude “it works.” That answer is beside the point. The compliance exposure is not on the screen — it is in where the data and its description live and how they move: the warehouse that holds the China-origin rows, and the project, logs, artifacts and metadata dbt keeps about them, which on dbt Cloud sit in a region dbt lists as North America, Europe, Australia or Japan — never mainland China. A page-load test measures none of that. It cannot see which region the warehouse is in, where dbt’s metadata rests, whether separate consent was taken, whether a transfer mechanism is in place, or that a China-facing dashboard needs an ICP filing.
There is a second trap specific to a transformation tool. Making the offshore dbt Cloud control plane merely reachable — even running a dbt command from inside China — does not move any of the regulated data in-country. dbt’s compute runs in the warehouse, so if the warehouse is offshore the data stays offshore; and the project, run history and metadata still live wherever the Cloud tenant runs. Where the warehouse and the control plane sit is what holds the data, and a command run from a mainland terminal is neither. That is the competitor-proof second half of the question — and it is why keeping the warehouse, the dbt run and its metadata in-country, not merely reachable, is the answer.
The lawful path — map, localize, deliver
There is a compliant way to run dbt for a mainland-China data team, and because dbt’s engine is open source and self-hosted it sits on the stack you already use — no rebuild, no migration off dbt.
First, map: our China compliance team inventories what your dbt footprint carries — which sources and destinations your models read and write, whether personal information is in the tables dbt transforms, where the warehouse lives, where the dbt run executes, and where its project, logs, artifacts and metadata rest (an offshore dbt Cloud region, or a self-hosted instance). We establish the consent and residency basis each flow relies on and build the technical picture; the legal conclusions are settled with counsel.
Then localize: run dbt’s self-hosted engine in-country against an in-country warehouse so the data and its transformation come to rest on mainland soil, keep the project, run history and metadata resident rather than on an offshore Cloud tenant, obtain the Article 13/23 notice and separate consent, treat any government IDs or financial data in tables or fixtures as sensitive personal information, and use a lawful cross-border mechanism (a CAC security assessment, the standard contract, or certification) only where a transfer is truly needed. Localize means standing up a lawful, in-country dbt — never a route that ships the data offshore anyway, and never any form of circumvention.
Then deliver: any public, China-facing surface built on dbt’s outputs — a BI dashboard, a data app, or hosted documentation your mainland users reach — is an internet information service, so it carries an ICP filing duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — in front of what you already run, so it serves your users in China legally and compliantly. 21YunBox never uses or suggests circumvention of any kind — we keep in-country what the law says must stay, deliver the rest compliantly from inside the mainland, and never move personal information across the border by stealth. 21YunBox is a compliance overlay and partner to the dbt you already run, not a competitor to it.
None of this is a verdict that dbt is “blocked” or “illegal” in China. It is a residency-and-consent map, and which duties bite your case turns on your entity, your role under Chinese law, your data volumes, and what your warehouse and models actually hold — worth settling the specifics with counsel before your China team’s data and its structural map depend on it.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law (data localization, Article 39)
- China’s Personal Information Protection Law (PIPL)
- How to get an ICP filing for China
