Ist Supabase DSGVO-konform? Wo Ihre Daten wirklich liegen

Ich bin Denys, Full-Stack- und KI-Entwickler, und die meisten Apps, die ich baue oder repariere, laufen auf Supabase. Europäische Kunden stellen vor allem anderen zwei Fragen: Ist Supabase DSGVO-konform, und wo liegen die Daten? Dieser Artikel beantwortet beide aus Supabases und Lovables eigenen Dokumenten, gelesen am 29. Oktober 2026, dazu die Befehle, mit denen ich ein Projekt prüfe.

Ist Supabase DSGVO-konform?

Supabases DSGVO-Leitfaden beschreibt es als geteilte Verantwortung: Supabase sichert die Infrastruktur, und Sie sind verantwortlich für die Datenverarbeitung Ihrer Anwendung, die Einwilligungsabläufe und die Zugriffskontrollen. Im Sinne der DSGVO ist Supabase Ihr Auftragsverarbeiter für die Daten, die Sie speichern, und sein Data Processing Addendum ist der Vertrag, der das festhält. Dasselbe Dokument nennt Supabase für eine Kategorie Verantwortlichen: die Nutzungsdaten, die es zum Betrieb der Plattform erhebt.

Zwei Teile dieses DPA zählen in der Praxis:

• Region. Wenn Sie Supabase anweisen, Daten in einer Region zu verarbeiten, speichert und verarbeitet es sie dort hauptsächlich, es sei denn, das Gesetz, Ihre eigenen Anweisungen oder der angeforderte Dienst erfordern etwas anderes.
• Unterauftragsverarbeiter. Sie genehmigen Supabases Liste der Unterauftragsverarbeiter im Voraus, und Supabase kündigt Änderungen 30 Tage vorher an. Auf derselben Seite können Sie diese Änderungen abonnieren. Die Liste enthält AWS und Cloudflare für das Hosting sowie Dienstleister für Support, Fehlerüberwachung und Nachrichten an Kontonutzer.

Wo speichert Supabase Ihre Daten?

Die FAQ zu Datenresidenz und die Seite zu den Regionen teilen es so auf:

Bestandteil Ihres Projekts	Wo er verarbeitet wird
Postgres-Datenbank und ihre Backups	In der gewählten AWS-Region
Auth (Nutzer, Sitzungen)	In der gewählten Region
Storage-Dateien am Ursprung	In der gewählten Region
Storage-CDN-Cache	Weltweit, bei Cloudflare zwischengespeichert
Edge Functions	An dem Edge-Standort, der dem Aufrufer am nächsten liegt, sofern nicht an eine Region gebunden
Plattform-Logs und Telemetrie	Außerhalb Ihrer Region; Logs liegen in EU-Rechenzentren
Support-Zugriff	Ein globales Support-Team, auf Ihre Anfrage oder bei einem Sicherheitsvorfall, protokolliert
Ihre Konto- und Abrechnungsdaten	Supabases zentrale Systeme; Supabase ist hier der Verantwortliche

Die FAQ beantwortet die direkte Frage eindeutig: Supabase garantiert nicht, dass Ihre Daten die Region nie verlassen. Datenbank und Backups bleiben; die vier Kategorien am Ende der Tabelle können sie verlassen.

Welche Supabase-Regionen liegen in der EU?

Vier bestimmte Regionen liegen innerhalb der EU: West EU (Ireland) eu-west-1, West EU (Paris) eu-west-3, Central EU (Frankfurt) eu-central-1 und North EU (Stockholm) eu-north-1. London eu-west-2 und Zürich eu-central-2 liegen in Europa und haben DSGVO-Angemessenheitsbeschlüsse, sind aber keine EU-Mitgliedstaaten.

Diese Unterscheidung zählt beim Anlegen des Projekts. Die allgemeine Option “Europe” lässt Supabase nach Kapazität eine verfügbare europäische Region wählen, und der Leitfaden zu den Regionen warnt, dass es London oder Zürich sein kann. Wenn Ihr Vertrag oder Ihr Kunde “Daten bleiben in der EU” verlangt, wählen Sie eine konkrete EU-Region. Noch ein Detail, falls Sie regionale Edge Functions nutzen: Laut der Regionen-Seite ist das Festlegen einer Funktion auf eine Region in Ohio und Stockholm nicht möglich.

Wie prüfen Sie die Region Ihres Projekts?

Im Dashboard steht die Region in den Einstellungen des Projekts. Im Terminal listet die Supabase CLI jedes Projekt, auf das Sie Zugriff haben, mit seiner Region auf:

supabase projects list
supabase projects list -o json   # each project has a "region" field, e.g. "eu-west-1"

Ich habe das in meinem eigenen Konto mit CLI 2.109.1 ausgeführt: Jedes Projekt kam mit seinem AWS-Regionscode zurück, ein kurzer Blick zeigt also, ob ein Projekt außerhalb der EU liegt.

Lässt sich die Region ändern? Nein. Supabases Hinweis zur Fehlerbehebung sagt, dass ein Projekt auf Infrastrukturebene an seine Region gebunden ist. Ein Umzug bedeutet, ein neues Projekt in der Zielregion anzulegen und dorthin zu migrieren, danach API-URL und Keys in der App zu aktualisieren und die Secrets von Drittanbieter-Anmeldungen von Hand zu kopieren. Auch eine Projektübertragung an eine andere Organisation ändert die Region nicht.

Ist Lovable DSGVO-konform?

Lovable bietet einen Auftragsverarbeitungsvertrag an und lässt das Backend (Lovable Cloud) in der Region Europe anlegen, DSGVO-konform wird Ihre Lovable-App dadurch aber nicht von selbst: Region, Vertrag und Ihre eigene Verarbeitung müssen zusammenpassen. Eine Lovable-Cloud-App betreibt ihr Backend nach demselben Modell, es gelten also dieselben Fragen, nur mit Lovables Einstellungen davor. Aus Lovables Backend-Dokumentation, Datenbank-Dokumentation und der DPA-Seite:

• Die Region ist Americas, Europe oder Asia Pacific, gewählt beim Aktivieren des Backends. Ein von einem Admin gesetzter Standard des Workspaces hat Vorrang (Tarife Business und Enterprise). Sonst nutzt Lovable Ihre eigene Einstellung “where project data is stored” und ohne sie die Region, die Ihnen am nächsten liegt.
• Sie sehen sie womöglich nie. Steht Enable Cloud auf “Always allow”, legt Lovable das Backend in dieser Region an, ohne zu fragen. Nur “Ask each time” zeigt die Region zuerst.
• Sie lässt sich nicht ändern. Lovable sagt klar, dass sich die Region eines Projekts nicht ändern und ein bestehendes Projekt nicht verschieben lässt.
• Prüfen Sie sie unter More → Database → Manage → Settings, in der Zeile Database location, zum Beispiel “Europe (Frankfurt)”.
• Die Seite selbst wird weltweit ausgeliefert, unabhängig von der Region; die Region betrifft nur das Backend.
• KI-Anfragen sind getrennt. KI-Modellanfragen in der EU zu halten, ist eine Einstellung namens EU inference, in Enterprise-Workspaces.
• Das DPA ist in den Tarifen Business und Enterprise enthalten.

Wenn Sie das Backend also von außerhalb Europas aktiviert haben, ohne eigene Einstellung, kann es in einer anderen Region liegen, und bei “Always allow” fragt Lovable nicht. Prüfen Sie die Zeile Database location, bevor sich Ihr erster echter Nutzer anmeldet.

Was die Region nicht löst

Supabases eigener Leitfaden sagt es: Die Wahl einer Region ist eine Kontrolle über den Datenstandort und macht eine Anwendung nicht von sich aus DSGVO-konform. Die Lücken, die ich am häufigsten finde, liegen in der App, nicht in der Plattform:

1. Personenbezogene Daten, die jeder lesen kann. Eine Tabelle mit RLS aus oder mit einer Policy, die jede Zeile erlaubt, liefert Namen und E-Mail-Adressen an jeden mit dem öffentlichen Key. Der kostenlose Supabase-Sicherheitscheck meldet Tabellen ohne RLS, Policies, die jede Zeile erlauben, und sensibel wirkende Spalten, die anonyme Besucher lesen können.
2. Konten mit fremder Adresse. Bei ausgeschalteter E-Mail-Bestätigung kann sich jeder mit einer Adresse anmelden, die ihm nicht gehört.
3. Dateien in öffentlichen Buckets. Ein öffentlicher Bucket liefert jede Datei an jeden mit ihrer URL, und das CDN cacht sie weltweit.
4. Dienstleister, die Sie selbst hinzugefügt haben. Jeder E-Mail-, SMS-, KI- oder Analysedienst, den Ihre Edge Functions aufrufen, ist Ihr Auftragsverarbeiter und nicht Supabases und braucht einen eigenen Vertrag.
5. Löschung und Aufbewahrung. Ein Löschverlangen scheitert, wenn Fremdschlüssel das Löschen eines Nutzers blockieren, der Inhalte verfasst hat, und Logs, die Adressen ewig behalten, sind ein Aufbewahrungsproblem.

Die letzten beiden und vier weitere gehe ich im DSGVO-Abschnitt meiner Sicherheits-Checkliste für Lovable-Apps durch. Was Supabase über die DSGVO hinaus zertifiziert, steht in Wie sicher ist Supabase?. Dieser Artikel ist keine Rechtsberatung; Ihr Datenschutzbeauftragter oder Anwalt entscheidet, was Ihre Verarbeitung braucht.