Does PostgreSQL Work in China? Data Residency, Localization & PIPL Cross-Border
PostgreSQL is free, open-source software that runs anywhere you install it — including self-hosted on mainland-China soil, the lawful lever. The compliance question is where you run it: an offshore managed service with no mainland-China region leaves your China records abroad, a PIPL cross-border transfer. A compliance-first look at where your database data is allowed to rest.
Does PostgreSQL work in China?
Whether PostgreSQL works in China is a data-residency question, not a reachability one — and the engine itself is the lawful lever. PostgreSQL is free, open-source software that runs on every major operating system, including self-hosted on a server inside mainland China; it is never "blocked."
Because PostgreSQL is residency-neutral, where your data comes to rest is decided by where you deploy it — not by the engine. Run it self-hosted in-country, or on a licensed domestic managed service (such as Alibaba Cloud's ApsaraDB RDS for PostgreSQL in its mainland regions), and your China records stay on mainland soil. Run it on an offshore managed service with no mainland-China region — Google Cloud SQL, Supabase and Neon list none — and the customer accounts, user profiles and transactions it holds sit abroad: a cross-border transfer of personal information PIPL governs (Articles 38–40), and for a critical-information-infrastructure operator or high-volume handler, a breach of the in-country storage duty (PIPL Article 40; Cybersecurity Law Article 39, formerly Article 37). Sovereign partitions exist — AWS China via Sinnet and NWCD, Azure China via 21Vianet — but each is a separate operator with its own account, ICP and feature gaps, so an in-country region is not automatic compliance.
This is a risk map, not a ruling — your obligations turn on your entity, your data volumes and whose personal information sits in the database. Our China team can map your PostgreSQL data exposure with you →
What PostgreSQL's own documentation says about China
| Fact | Primary source |
|---|---|
| PostgreSQL is residency-neutral, self-hostable software — not a vendor or a hosting location. Its own About page describes PostgreSQL as "free and open source" software that "runs on all major operating systems," maintained by the community-run PostgreSQL Global Development Group. You download and run the engine yourself, so where the data comes to rest is set entirely by where you deploy it — including self-hosted on mainland-China infrastructure, which keeps the data on mainland soil (the lawful lever). | PostgreSQL project — About page, retrieved 2026-10-10 |
| Offshore managed Postgres services have no mainland-China region. Google's own Cloud SQL locations page states that "when you create a Cloud SQL instance, you choose a region where the instance and its data are stored," and lists more than forty regions — including Hong Kong (asia-east2) and Taiwan (asia-east1) — with none in mainland China. The serverless-Postgres clouds Supabase and Neon likewise list no mainland-China region. Licensed in-country managed options do exist (for example Alibaba Cloud's ApsaraDB RDS for PostgreSQL in its mainland regions), as do separate sovereign partitions — AWS China, operated by Sinnet and NWCD, and Azure China, operated by 21Vianet. | Google Cloud SQL for PostgreSQL — Manage instance locations, retrieved 2026-10-10 |
| China customer and user records stored offshore are a cross-border transfer under PIPL. A relational database is where personal information comes to rest — accounts, profiles, orders and transactions. Records collected in the mainland and stored in an offshore PostgreSQL deployment are an export PIPL governs, requiring notice, a separate consent, and one transfer mechanism (PIPL Articles 38–40), with a possible CAC security assessment above volume or sensitivity thresholds — and the handler on the hook is you, not the open-source project. | Personal Information Protection Law of the PRC, Articles 28 and 38–40 |
| CIIOs and high-volume handlers owe an in-country storage duty an offshore database cannot meet. Personal information and important data collected in the mainland must be stored in the mainland (PIPL Article 40; 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. Because PostgreSQL runs identically in-country, self-hosting on mainland infrastructure (or a licensed domestic managed service) meets this duty without a migration. | PIPL Article 40; PRC Cybersecurity Law Article 39 (formerly Article 37) |
Sources verified by the 21YunBox compliance team on 2026-10-10.
For a team serving mainland China, the question about PostgreSQL was never whether it installs or connects. It does: PostgreSQL is free, open-source software that runs on every major operating system, and it runs as well on a server in Shanghai as on one in Virginia. A relational database is where your records physically come to rest — customer accounts, user profiles, orders and transactions, support histories, the personal information of whoever uses your product. So the real question is a residency one: where is that data allowed to live? PostgreSQL itself is residency-neutral. The community-run PostgreSQL Global Development Group ships an engine, not a hosting location, and where the data rests is decided entirely by where you deploy it — self-hosted or on a licensed domestic managed service in-country, it stays on mainland soil; on an offshore managed service with no mainland-China region, your China records sit abroad.
PostgreSQL in China at a glance
| What decides it | In PostgreSQL's own terms — and China's law |
|---|---|
| Where the records physically rest | PostgreSQL is residency-neutral: its own site calls it "free and open source" software that "runs on all major operating systems." Where the data comes to rest is set by where you deploy it — self-hosted on mainland infrastructure, a licensed domestic managed service (such as Alibaba Cloud's ApsaraDB RDS for PostgreSQL in its mainland regions), or an offshore managed service. Offshore managed Postgres — Google Cloud SQL, and serverless clouds such as Supabase and Neon — lists no mainland-China region. |
| What it holds, and why it's personal information | A relational database is where personal information comes to rest: the names, emails, account numbers, order and transaction histories, and device identifiers of your China customers, and the HR and identity records of your China employees. It is personal information the moment it describes an identifiable person — and a single table can hold Article 28 sensitive personal information: financial, government-ID, precise-location or health fields. |
| Your mainland data in the database | Records collected in China and stored in an offshore PostgreSQL deployment are a cross-border transfer PIPL governs: notice, a separate consent, and one transfer mechanism (PIPL Articles 38–40). The handler on the hook is you, the operator — not the open-source project. |
| In-country storage duty | A critical information infrastructure operator or high-volume handler owes an in-country storage duty an offshore database cannot meet — mainland personal information and important data must stay in the mainland (PIPL Article 40; 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. |
| Is it reachable? | Treat reachability as the delivery half, not the question — the engine runs fine in-country. The lawful lever is to run it in-country (self-hosted, or a licensed/sovereign managed option), and any China-facing surface in front of it — an app, an API edge, an admin or reporting portal — needs an ICP filing tied to a mainland hosting resource (State Council Order No. 292; MIIT Order No. 33). |
Where the data actually rests
PostgreSQL does not have a region; your deployment does. The engine is the same bits whether it runs in Frankfurt, Singapore or Shanghai, so the residency question is entirely about the host you put it on.
On an offshore managed service, that host is outside the mainland. Google’s own Cloud SQL locations page says that “when you create a Cloud SQL instance, you choose a region where the instance and its data are stored,” then lists more than forty regions — Hong Kong (asia-east2) and Taiwan (asia-east1) among them — with none in mainland China. The serverless-Postgres clouds Supabase and Neon likewise publish region lists with no mainland-China option. Point your production database at any of these and your China customer and user records come to rest abroad; under the Personal Information Protection Law, that is a cross-border transfer, and the handler responsible is you.
In-country options genuinely exist, and they are the lawful lever. You can self-host PostgreSQL on mainland infrastructure, where the engine runs identically. You can use a licensed domestic managed service — Alibaba Cloud’s ApsaraDB RDS for PostgreSQL runs in its mainland regions, for instance. And the large foreign clouds reach China only through separate sovereign partitions: AWS China (the Beijing region operated by Sinnet and the Ningxia region operated by NWCD) and Azure China (operated by 21Vianet) are distinct clouds with their own accounts, their own ICP, and their own feature and availability gaps. An in-country region is not automatic compliance — it is the starting point for it.
What it holds is personal information
A database earns this scrutiny because of what it stores. Unlike a tool that touches one slice of your data, your primary datastore is where the whole record of a customer relationship lands: the account, the profile, the orders, the payments, the messages. Every one of those rows is personal information under PIPL the moment it identifies a person, and some of it is Article 28 sensitive personal information — financial records, government-issued IDs, precise location, biometric or health data — which carries a higher bar: a specific purpose, strict necessity, and separate consent.
That is why residency is not merely good practice here. For a critical information infrastructure operator, and for a handler whose volumes cross the regulators’ thresholds, personal information and important data collected in the mainland must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). An offshore database structurally cannot satisfy that duty — the data is, by definition, in the wrong country. And where an export is permitted at all, crossing a volume or sensitivity threshold can trigger a CAC-led data-export security assessment before any of it lawfully leaves.
Running it offshore doesn’t meet the residency duty — and what does
The honest summary is narrow and important: nothing about PostgreSQL is “blocked,” and you do not need to leave it. The exposure is not the software; it is a deployment that parks mainland personal information outside the mainland. Fix the deployment and the exposure closes.
The lawful lever is to run the same PostgreSQL in-country. Self-hosted on mainland infrastructure, or on a licensed domestic or sovereign-cloud managed service, the engine behaves exactly as it does abroad — same SQL, same extensions, same backups and replication — so the records China requires to stay in-country do, with no rewrite and no second schema. Tunnelling a mainland application back to an offshore endpoint is not localization and does not meet the storage duty; standing up a lawful in-country equivalent is. Where a subset of data may lawfully leave, you keep that transfer minimized, consented, and backed by a transfer mechanism, while a China-facing surface in front of the database earns its own ICP filing.
This is a risk map, not a verdict. Whether you owe in-country storage, a transfer mechanism, a separate consent, an ICP filing, or some combination turns on your entity, your data volumes, how much of what you hold is personal or sensitive, and who your users are — and it is worth settling with counsel before you decide where a single mainland record lives.
The lawful path — map, localize, deliver
You do not have to drop PostgreSQL to run it lawfully for mainland China. 21YunBox is a compliant overlay, not a migration — and, for an open-source engine you already run, a partner that sits alongside your stack, not a competitor to it. There are three moves, and they fit together.
Map. Our China compliance team reads your PIPL cross-border, data-residency and data-localization (CII) obligations against your actual entity, your data volumes, and whose personal information sits in the database — so the exposure is written down before anything is moved.
Localize. Because the risk is where the data rests, we run the database in-country — self-hosted on mainland infrastructure, or on a licensed domestic or sovereign-cloud managed option — so the personal information China requires to stay on mainland soil does. Localize means a lawful in-country deployment of the same engine, never a tunnel back to an offshore endpoint; only the minimized, lawfully transferable subset ever crosses.
Deliver. For any China-facing surface in front of the database — the app, the API edge, the admin or reporting portal your mainland users hit — the 21YunBox Optimizer provides ICP-filed, in-country delivery, in front of the stack you already run. No rebuild, no second codebase. 21YunBox never uses or suggests circumvention of any kind; the entire point is a lawful, filed, in-country path.
The goal is plain: your PostgreSQL database runs legally and compliantly for your users in China.
Related reading:
- How to get an ICP filing for China
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- China’s data-export security assessment measures
