Funktioniert PostgreSQL in China? Datenresidenz, Lokalisierung und PIPL-Grenztransfer
PostgreSQL ist freie, quelloffene Software, die überall läuft, wo Sie sie installieren — auch selbstgehostet auf Festlandchina-Boden, dem rechtmäßigen Hebel. Die Compliance-Frage ist, wo Sie es betreiben: Ein Offshore-Managed-Service ohne Festland-China-Region lässt Ihre China-Datensätze im Ausland, ein PIPL-Grenztransfer. Ein Blick zuerst auf die Compliance: wo Ihre Datenbankdaten ruhen dürfen.
Funktioniert PostgreSQL in China?
Ob PostgreSQL in China funktioniert, ist eine Datenresidenzfrage, keine Erreichbarkeitsfrage — und die Engine selbst ist der rechtmäßige Hebel. PostgreSQL ist freie, quelloffene Software, die auf jedem großen Betriebssystem läuft, auch selbstgehostet auf einem Server innerhalb Festlandchinas; es ist nie „gesperrt“.
Weil PostgreSQL residenzneutral ist, entscheidet sich, wo Ihre Daten zur Ruhe kommen, danach, wo Sie es deployen — nicht nach der Engine. Betreiben Sie es selbstgehostet im Inland oder auf einem lizenzierten inländischen Managed-Service (etwa Alibaba Clouds ApsaraDB RDS for PostgreSQL in seinen Festland-Regionen), und Ihre China-Datensätze bleiben auf Festland-Boden. Betreiben Sie es auf einem Offshore-Managed-Service ohne Festland-China-Region — Google Cloud SQL, Supabase und Neon nennen keine —, und die Kundenkonten, Nutzerprofile und Transaktionen, die es hält, sitzen im Ausland: ein grenzüberschreitender Transfer personenbezogener Daten, den PIPL regelt (Art. 38–40), und, für einen Betreiber kritischer Informationsinfrastruktur oder hochvolumigen Verarbeiter, ein Verstoß gegen die inländische Speicherpflicht (PIPL Art. 40; Cybersicherheitsgesetz Art. 39, vormals Art. 37). Sovereign-Partitionen existieren — AWS China über Sinnet und NWCD, Azure China über 21Vianet —, aber jede ist ein eigener Betreiber mit eigenem Konto, eigener ICP und eigenen Funktionslücken, eine inländische Region ist also nicht automatisch Compliance.
Dies ist eine Risikokarte, kein Urteil — Ihre Pflichten hängen von Ihrer Gesellschaft, Ihren Datenmengen und davon ab, wessen personenbezogene Daten in der Datenbank sitzen. Unser China-Team kann Ihre PostgreSQL-Datenexponierung mit Ihnen kartieren →
Compliance-Momentaufnahme
- ! PostgreSQL ist residenzneutral: Wo seine Daten ruhen, bestimmt sich danach, wo Sie es deployen
- ✕ Ein Offshore-Managed-Postgres ohne Festland-China-Region lässt Ihre China-Daten im Ausland
- ! China-Datensätze in einer Offshore-Region sind ein PIPL-Grenztransfer (Art. 38–40)
- ! CIIO / hochvolumige Verarbeiter schulden eine inländische Speicherpflicht, die eine Offshore-DB nicht erfüllen kann
- ! Inländische Optionen existieren — Self-Host, Alibaba ApsaraDB, Sovereign-Clouds — mit Lücken
- ✓ Rechtmäßiger Weg: Exponierung kartieren, inländische Speicherung lokalisieren, ICP-gemeldete inländische Auslieferung
Was die offizielle PostgreSQL-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| PostgreSQL ist residenzneutrale, selbst hostbare Software — kein Anbieter und kein Hosting-Standort. Seine eigene About-Seite beschreibt PostgreSQL als „free and open source“-Software, die „runs on all major operating systems“ (auf allen großen Betriebssystemen läuft), gepflegt von der von der Community betriebenen PostgreSQL Global Development Group. Sie laden die Engine herunter und betreiben sie selbst, wo die Daten also zur Ruhe kommen, bestimmt sich ganz danach, wo Sie es deployen — auch selbstgehostet auf Festlandchina-Infrastruktur, was die Daten auf Festland-Boden hält (der rechtmäßige Hebel). | PostgreSQL project — About page, abgerufen 2026-10-10 |
| Offshore-Managed-Postgres-Dienste haben keine Festland-China-Region. Googles eigene Cloud-SQL-Standortseite gibt an, dass „when you create a Cloud SQL instance, you choose a region where the instance and its data are stored“ (wenn Sie eine Cloud-SQL-Instanz erstellen, wählen Sie eine Region, in der die Instanz und ihre Daten gespeichert werden), und listet mehr als vierzig Regionen — einschließlich Hongkong (asia-east2) und Taiwan (asia-east1) — mit keiner in Festlandchina. Die Serverless-Postgres-Clouds Supabase und Neon listen ebenso keine Festland-China-Region. Lizenzierte inländische Managed-Optionen existieren (zum Beispiel Alibaba Clouds ApsaraDB RDS for PostgreSQL in seinen Festland-Regionen), ebenso separate Sovereign-Partitionen — AWS China, betrieben von Sinnet und NWCD, und Azure China, betrieben von 21Vianet. | Google Cloud SQL for PostgreSQL — Manage instance locations, abgerufen 2026-10-10 |
| Im Ausland gespeicherte China-Kunden- und Nutzer-Datensätze sind ein grenzüberschreitender Transfer nach PIPL. Eine relationale Datenbank ist, wo personenbezogene Daten zur Ruhe kommen — Konten, Profile, Bestellungen und Transaktionen. Im Festland erhobene und in einem Offshore-PostgreSQL-Deployment gespeicherte Datensätze sind ein Export, den PIPL regelt und der Mitteilung, eine gesonderte Einwilligung und einen Transfermechanismus verlangt (PIPL Art. 38–40), mit einer möglichen CAC-Sicherheitsbewertung oberhalb von Mengen- oder Sensibilitätsschwellen — und der Verarbeiter am Haken sind Sie, nicht das Open-Source-Projekt. | Personal Information Protection Law of the PRC, Articles 28 and 38–40 |
| CIIOs und hochvolumige Verarbeiter schulden eine inländische Speicherpflicht, die eine Offshore-Datenbank nicht erfüllen kann. Im Festland erhobene personenbezogene Daten und wichtige Daten müssen im Festland gespeichert werden (PIPL Art. 40; Cybersicherheitsgesetz Art. 39, vormals Art. 37). Die Novelle 2025 des Cybersicherheitsgesetzes, in Kraft seit 1. Januar 2026, hat den Datenlokalisierungsartikel von 37 auf 39 umnummeriert, inhaltlich unverändert. Weil PostgreSQL im Inland identisch läuft, erfüllt Selbst-Hosting auf Festland-Infrastruktur (oder ein lizenzierter inländischer Managed-Service) diese Pflicht ohne eine Migration. | PIPL Article 40; PRC Cybersecurity Law Article 39 (formerly Article 37) |
Quellen vom 21YunBox Compliance-Team am 10. Oktober 2026 geprüft.
Für ein Team, das Festlandchina bedient, war die Frage zu PostgreSQL nie, ob es installiert oder sich verbindet. Das tut es: PostgreSQL ist freie, quelloffene Software, die auf jedem großen Betriebssystem läuft, und sie läuft auf einem Server in Shanghai so gut wie auf einem in Virginia. Eine relationale Datenbank ist, wo Ihre Datensätze physisch zur Ruhe kommen — Kundenkonten, Nutzerprofile, Bestellungen und Transaktionen, Support-Verläufe, die personenbezogenen Daten derer, die Ihr Produkt nutzen. Die eigentliche Frage ist also eine Residenzfrage: Wo dürfen diese Daten leben? PostgreSQL selbst ist residenzneutral. Die von der Community betriebene PostgreSQL Global Development Group liefert eine Engine, keinen Hosting-Standort, und wo die Daten ruhen, entscheidet sich ganz danach, wo Sie es deployen — selbstgehostet oder auf einem lizenzierten inländischen Managed-Service im Inland bleibt es auf Festland-Boden; auf einem Offshore-Managed-Service ohne Festland-China-Region sitzen Ihre China-Datensätze im Ausland.
PostgreSQL in China auf einen Blick
| Worüber es entscheidet | In PostgreSQLs eigenen Worten — und nach chinesischem Recht |
|---|---|
| Wo die Datensätze physisch ruhen | PostgreSQL ist residenzneutral: Seine eigene Seite nennt es „free and open source“-Software, die „runs on all major operating systems“ (auf allen großen Betriebssystemen läuft). Wo die Daten zur Ruhe kommen, bestimmt sich danach, wo Sie es deployen — selbstgehostet auf Festland-Infrastruktur, ein lizenzierter inländischer Managed-Service (etwa Alibaba Clouds ApsaraDB RDS for PostgreSQL in seinen Festland-Regionen) oder ein Offshore-Managed-Service. Offshore-Managed-Postgres — Google Cloud SQL und Serverless-Clouds wie Supabase und Neon — nennt keine Festland-China-Region. |
| Was es hält, und warum es personenbezogen ist | Eine relationale Datenbank ist, wo personenbezogene Daten zur Ruhe kommen: die Namen, E-Mails, Kontonummern, Bestell- und Transaktionsverläufe und Geräte-Identifikatoren Ihrer China-Kunden und die HR- und Identitätsdatensätze Ihrer China-Mitarbeiter. Es ist personenbezogen in dem Moment, in dem es eine identifizierbare Person beschreibt — und eine einzige Tabelle kann sensible personenbezogene Daten nach Art. 28 halten: Finanz-, Behörden-ID-, Präzisionsstandort- oder Gesundheitsfelder. |
| Ihre Festland-Daten in der Datenbank | In China erhobene und in einem Offshore-PostgreSQL-Deployment gespeicherte Datensätze sind ein grenzüberschreitender Transfer, den PIPL regelt: Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus (PIPL Art. 38–40). Der Verarbeiter am Haken sind Sie, der Betreiber — nicht das Open-Source-Projekt. |
| Inländische Speicherpflicht | Ein Betreiber kritischer Informationsinfrastruktur oder hochvolumiger Verarbeiter schuldet eine inländische Speicherpflicht, die eine Offshore-Datenbank nicht erfüllen kann — personenbezogene Daten und wichtige Daten des Festlands müssen im Festland bleiben (PIPL Art. 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)) — die Novelle 2025 des Cybersicherheitsgesetzes, in Kraft seit 1. Januar 2026, hat den Datenlokalisierungsartikel von 37 auf 39 umnummeriert, inhaltlich unverändert. |
| Ist es erreichbar? | Behandeln Sie Erreichbarkeit als die Auslieferungshälfte, nicht als die Frage — die Engine läuft im Inland problemlos. Der rechtmäßige Hebel ist, es im Inland zu betreiben (selbstgehostet oder eine lizenzierte/Sovereign-Managed-Option), und jede auf China ausgerichtete Oberfläche davor — eine App, ein API-Edge, ein Admin- oder Reporting-Portal — braucht eine ICP-Beian, gebunden an eine Festland-Hosting-Ressource (Erlass Nr. 292 des Staatsrats; MIIT-Erlass Nr. 33). |
Wo die Daten tatsächlich ruhen
PostgreSQL hat keine Region; Ihr Deployment hat eine. Die Engine ist dieselben Bits, ob sie in Frankfurt, Singapur oder Shanghai läuft, die Residenzfrage dreht sich also ganz um den Host, auf den Sie sie setzen.
Auf einem Offshore-Managed-Service ist dieser Host außerhalb des Festlands. Googles eigene Cloud-SQL-Standortseite sagt, dass „when you create a Cloud SQL instance, you choose a region where the instance and its data are stored“ (wenn Sie eine Cloud-SQL-Instanz erstellen, wählen Sie eine Region, in der die Instanz und ihre Daten gespeichert werden), und listet dann mehr als vierzig Regionen — Hongkong (asia-east2) und Taiwan (asia-east1) darunter — mit keiner in Festlandchina. Die Serverless-Postgres-Clouds Supabase und Neon veröffentlichen ebenso Regionslisten ohne Festland-China-Option. Richten Sie Ihre Produktionsdatenbank auf eine dieser aus, und Ihre China-Kunden- und Nutzer-Datensätze kommen im Ausland zur Ruhe; nach dem Gesetz zum Schutz personenbezogener Daten ist das ein grenzüberschreitender Transfer, und der verantwortliche Verarbeiter sind Sie.
Inländische Optionen existieren wirklich, und sie sind der rechtmäßige Hebel. Sie können PostgreSQL auf Festland-Infrastruktur selbst hosten, wo die Engine identisch läuft. Sie können einen lizenzierten inländischen Managed-Service nutzen — Alibaba Clouds ApsaraDB RDS for PostgreSQL läuft etwa in seinen Festland-Regionen. Und die großen ausländischen Clouds erreichen China nur über separate Sovereign-Partitionen: AWS China (die Region Peking, betrieben von Sinnet, und die Region Ningxia, betrieben von NWCD) und Azure China (betrieben von 21Vianet) sind eigenständige Clouds mit eigenen Konten, eigener ICP und eigenen Funktions- und Verfügbarkeitslücken. Eine inländische Region ist nicht automatisch Compliance — sie ist der Ausgangspunkt dafür.
Was es hält, sind personenbezogene Daten
Eine Datenbank verdient diese Prüfung wegen dessen, was sie speichert. Anders als ein Werkzeug, das eine Scheibe Ihrer Daten berührt, ist Ihr primärer Datenspeicher, wo der ganze Datensatz einer Kundenbeziehung landet: das Konto, das Profil, die Bestellungen, die Zahlungen, die Nachrichten. Jede dieser Zeilen ist personenbezogen nach PIPL in dem Moment, in dem sie eine Person identifiziert, und ein Teil davon sind sensible personenbezogene Daten nach Art. 28 — Finanzdatensätze, behördlich ausgestellte IDs, Präzisionsstandort, biometrische oder Gesundheitsdaten —, die eine höhere Schwelle tragen: einen spezifischen Zweck, strikte Notwendigkeit und gesonderte Einwilligung.
Deshalb ist Residenz hier nicht bloß gute Praxis. Für einen Betreiber kritischer Informationsinfrastruktur und für einen Verarbeiter, dessen Mengen die Schwellen der Regulierer überschreiten, müssen personenbezogene Daten und wichtige Daten, die im Festland erhoben wurden, im Festland gespeichert werden (PIPL Art. 40; Cybersicherheitsgesetz Art. 39 (vormals Art. 37)). Eine Offshore-Datenbank kann diese Pflicht strukturell nicht erfüllen — die Daten sind per Definition im falschen Land. Und wo ein Export überhaupt erlaubt ist, kann das Überschreiten einer Mengen- oder Sensibilitätsschwelle eine CAC-geführte Datenexport-Sicherheitsbewertung auslösen, bevor irgendetwas davon rechtmäßig das Land verlässt.
Es im Ausland zu betreiben, erfüllt die Residenzpflicht nicht — und was sie erfüllt
Die ehrliche Zusammenfassung ist eng und wichtig: Nichts an PostgreSQL ist „gesperrt“, und Sie müssen es nicht verlassen. Die Exponierung ist nicht die Software; sie ist ein Deployment, das personenbezogene Festland-Daten außerhalb des Festlands parkt. Reparieren Sie das Deployment, und die Exponierung schließt sich.
Der rechtmäßige Hebel ist, dasselbe PostgreSQL im Inland zu betreiben. Selbstgehostet auf Festland-Infrastruktur oder auf einem lizenzierten inländischen oder Sovereign-Cloud-Managed-Service verhält sich die Engine genau wie im Ausland — dasselbe SQL, dieselben Extensions, dieselben Backups und Replikation —, sodass die Datensätze, die China im Inland halten muss, es auch tun, ohne Umschreibung und ohne zweites Schema. Eine Festland-Anwendung an einen Offshore-Endpunkt zurückzuleiten, ist keine Lokalisierung und erfüllt die Speicherpflicht nicht; einen rechtmäßigen inländischen Gegenwert aufzustellen, schon. Wo eine Teilmenge der Daten rechtmäßig das Land verlassen darf, halten Sie diesen Transfer minimiert, eingewilligt und durch einen Transfermechanismus gestützt, während eine auf China ausgerichtete Oberfläche vor der Datenbank ihre eigene ICP-Beian verdient.
Dies ist eine Risikokarte, kein Urteil. Ob Sie inländische Speicherung, einen Transfermechanismus, eine gesonderte Einwilligung, eine ICP-Beian oder eine Kombination schulden, hängt von Ihrer Gesellschaft, Ihren Datenmengen, wie viel von dem, was Sie halten, personenbezogen oder sensibel ist, und davon ab, wer Ihre Nutzer sind — und es lohnt sich, es mit Rechtsbeistand zu klären, bevor Sie entscheiden, wo ein einziger Festland-Datensatz lebt.
Der rechtmäßige Weg — kartieren, lokalisieren, ausliefern
Sie müssen PostgreSQL nicht aufgeben, um es rechtmäßig für Festlandchina zu betreiben. 21YunBox ist eine rechtskonforme Overlay, keine Migration — und, für eine Open-Source-Engine, die Sie bereits betreiben, eine Partnerin, die neben Ihrem Stack sitzt, keine Konkurrentin zu ihm. Es gibt drei Züge, und sie passen zusammen.
Kartieren. Unser China-Compliance-Team liest Ihre Pflichten bei PIPL-Grenztransfer, Datenresidenz und Datenlokalisierung (CII) gegen Ihre tatsächliche Gesellschaft, Ihre Datenmengen und wessen personenbezogene Daten in der Datenbank sitzen — sodass die Exponierung aufgeschrieben ist, bevor irgendetwas bewegt wird.
Lokalisieren. Weil das Risiko ist, wo die Daten ruhen, betreiben wir die Datenbank im Inland — selbstgehostet auf Festland-Infrastruktur oder auf einer lizenzierten inländischen oder Sovereign-Cloud-Managed-Option —, sodass die personenbezogenen Daten, die China auf Festland-Boden halten muss, es auch tun. Lokalisieren heißt ein rechtmäßiges inländisches Deployment derselben Engine, niemals eine Umleitung zurück zu einem Offshore-Endpunkt; nur die minimierte, rechtmäßig übertragbare Teilmenge überquert je die Grenze.
Ausliefern. Für jede auf China ausgerichtete Oberfläche vor der Datenbank — die App, der API-Edge, das Admin- oder Reporting-Portal, das Ihre Festland-Nutzer treffen — bietet der 21YunBox Optimizer ICP-gemeldete, inländische Auslieferung, vor dem Stack, den Sie bereits betreiben. Kein Neuaufbau, keine zweite Codebasis. 21YunBox verwendet oder empfiehlt niemals eine Umgehung welcher Art auch immer; der ganze Sinn ist ein rechtmäßiger, gemeldeter, inländischer Weg.
Das Ziel ist einfach: Ihre PostgreSQL-Datenbank läuft legal und rechtskonform für Ihre Nutzer in China.
Compliance-Einschätzung anfordern →
Weiterführend:
- So erhalten Sie eine ICP-Beian für China
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- Chinas Datenexport-Sicherheitsbewertungsmaßnahmen
Häufige Fragen
Ist PostgreSQL in China gesperrt?
Nein. PostgreSQL ist freie, quelloffene Software, die auf jedem großen Betriebssystem läuft, und sie läuft auf einem Server innerhalb Festlandchinas problemlos — es ist nie gesperrt. Die Compliance-Frage ist nicht, ob es läuft, sondern wo seine Daten ruhen dürfen: selbstgehostet oder auf einem lizenzierten inländischen Managed-Service im Inland hält China-Datensätze auf Festland-Boden, während ein Offshore-Managed-Service ohne Festland-China-Region sie im Ausland lässt, was PIPL als grenzüberschreitenden Transfer behandelt.
Welche Managed-PostgreSQL-Dienste haben eine Festland-China-Region?
Das Standard-Managed-Postgres der globalen Clouds — Google Cloud SQL, dazu Serverless-Clouds wie Supabase und Neon — nennt keine Festland-China-Region. Inländische Optionen existieren über verschiedene Betreiber: Alibaba Clouds ApsaraDB RDS for PostgreSQL läuft in seinen Festland-Regionen, AWS China (Peking und Ningxia) ist eine separate Partition, betrieben von Sinnet und NWCD, und Azure China wird von 21Vianet betrieben. Jede ist ein eigenes Konto mit eigener ICP, eigenen Funktions- und Verfügbarkeitslücken, eine inländische Region ist also ein Ausgangspunkt für Compliance, nicht automatisch Compliance.
Müssen wir von PostgreSQL migrieren, um in China rechtskonform zu sein?
Nein. Weil die Engine residenzneutral ist und im Inland identisch läuft, ist der rechtmäßige Weg, dasselbe PostgreSQL im Inland zu betreiben — selbstgehostet auf Festland-Infrastruktur oder auf einem lizenzierten inländischen oder Sovereign-Cloud-Managed-Service —, sodass die personenbezogenen Daten, die China im Inland halten muss, es auch tun. Das ist eine Deployment-Änderung, keine Umschreibung. Behandeln Sie dies als Risikokarte und klären Sie die Einzelheiten mit Rechtsbeistand gegen Ihre eigene Gesellschaft und Datenmengen.
