Är Supabase GDPR-kompatibelt? Var din data faktiskt finns

Jag heter Denys och är full-stack- och AI-ingenjör, och de flesta appar jag bygger eller rättar körs på Supabase. Europeiska kunder ställer två frågor före allt annat: är Supabase GDPR-kompatibelt, och var finns datan? Den här artikeln svarar på båda utifrån Supabases och Lovables egna dokument, lästa den 29 oktober 2026, plus kommandona jag använder för att kontrollera ett projekt.

Är Supabase GDPR-kompatibelt?

Supabases GDPR-guide beskriver det som ett delat ansvar: Supabase säkrar infrastrukturen, och du ansvarar för din applikations databehandling, samtyckesflöden och åtkomstkontroller. I GDPR-termer är Supabase ditt personuppgiftsbiträde för datan du lagrar, och dess Data Processing Addendum är avtalet som säger det. Samma dokument anger Supabase som personuppgiftsansvarig för en kategori, användningsdatan det samlar in för att driva plattformen.

Två delar av det DPA:t spelar roll i praktiken:

• Region. När du ber Supabase behandla data i en region lagrar och behandlar det dem i första hand där, om inte lagen, dina egna instruktioner eller tjänsten du bett om kräver något annat.
• Underbiträden. Du godkänner Supabases lista över underbiträden i förväg, och Supabase ger 30 dagars varsel innan listan ändras. Du kan prenumerera på ändringarna på samma sida. Listan omfattar AWS och Cloudflare för hosting, och tjänsteleverantörer för support, felövervakning och meddelanden till kontoanvändare.

Var lagrar Supabase din data?

FAQ:n om dataplacering och regionsidan delar upp det så här:

Del av ditt projekt	Var den behandlas
Postgres-databasen och dess säkerhetskopior	AWS-regionen du valde
Auth (användare, sessioner)	Regionen du valde
Storage-filer vid ursprunget	Regionen du valde
Storage-CDN:ets cache	Globalt, cachad på Cloudflare
Edge Functions	Vid edgen närmast anroparen, om du inte låser dem till en region
Plattformens loggar och telemetri	Utanför din region; loggar lagras i EU-datacenter
Supportåtkomst	Ett globalt supportteam, när du ber om hjälp eller vid en säkerhetsincident, loggad
Dina konto- och betalningsuppgifter	Supabases centrala system; Supabase är personuppgiftsansvarig här

FAQ:n svarar rakt på den burdusa frågan: Supabase garanterar inte att din data aldrig lämnar regionen. Din databas och dina säkerhetskopior stannar; de fyra kategorierna längst ned i tabellen kan lämna den.

Vilka Supabase-regioner ligger i EU?

Fyra bestämda regioner ligger inom EU: West EU (Ireland) eu-west-1, West EU (Paris) eu-west-3, Central EU (Frankfurt) eu-central-1 och North EU (Stockholm) eu-north-1. London eu-west-2 och Zürich eu-central-2 ligger i Europa och har beslut om adekvat skyddsnivå enligt GDPR, men är inte EU-medlemsstater.

Den skillnaden spelar roll när du skapar projektet. Det allmänna “Europe”-alternativet låter Supabase välja en ledig europeisk region efter kapacitet, och regionguiden varnar för att det kan bli London eller Zürich. Om ditt avtal eller din kund säger “data stannar i EU”, välj en bestämd EU-region. En detalj till om du använder regionala Edge Functions: regionsidan säger att det inte går att låsa en funktion till en region i Ohio eller Stockholm.

Hur kontrollerar du ditt projekts region?

I dashboarden visas regionen i projektets inställningar. Från en terminal listar Supabase CLI alla projekt du har åtkomst till med deras region:

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

Jag körde det på mitt eget konto med CLI 2.109.1: varje projekt kom tillbaka med sin AWS-regionkod, så en snabb blick visar om något projekt ligger utanför EU.

Kan du ändra den? Nej. Supabases felsökningsanteckning säger att ett projekt är bundet till sin region på infrastrukturnivå. Att flytta betyder att skapa ett nytt projekt i målregionen och migrera dit, och sedan uppdatera din API-URL och dina nycklar i appen och kopiera hemligheter för tredjepartsinloggning för hand. En projektöverföring till en annan organisation ändrar inte heller regionen.

Är Lovable Cloud GDPR-kompatibelt?

En Lovable Cloud-app kör sin backend efter samma modell, så samma frågor gäller, med Lovables inställningar framför. Från Lovables backend-dokumentation, databasdokumentation och DPA-sida:

• Regionen är en av Americas, Europe eller Asia Pacific, vald när backend aktiveras. En standard för arbetsytan, satt av en admin, går före (Business- och Enterprise-planer). Annars använder Lovable din egen inställning “where project data is stored”, och utan den regionen närmast dig.
• Du kanske aldrig ser den. Med Enable Cloud satt till “Always allow” skapar Lovable backend i den regionen utan att fråga. Bara “Ask each time” visar regionen först.
• Den kan inte ändras. Lovable säger rakt ut att ett projekts region inte kan ändras och att ett befintligt projekt inte kan flyttas.
• Kontrollera den under More → Database → Manage → Settings, i raden Database location, till exempel “Europe (Frankfurt)”.
• Själva sajten levereras globalt, oavsett region; regionen täcker bara backend.
• AI-förfrågningar är en separat sak. Att hålla förfrågningar till AI-modeller i EU är en inställning som heter EU inference, på Enterprise-arbetsytor.
• DPA:t ingår på Business- och Enterprise-planer.

Så om du aktiverade backend medan du arbetade utanför Europa, utan en egen inställning, kan backend ligga i en annan region, och med “Always allow” på frågar Lovable inte. Kontrollera raden Database location innan din första riktiga användare registrerar sig.

Vad regionen inte löser

Supabases egen guide säger det: att välja en region är en kontroll av dataplacering och gör inte i sig en applikation GDPR-kompatibel. Luckorna jag oftast hittar finns i appen, inte i plattformen:

1. Personuppgifter som vem som helst kan läsa. En tabell med RLS av, eller en policy som släpper igenom varje rad, serverar namn och e-postadresser till den som har den publika nyckeln. Den gratis Supabase säkerhetskontrollen flaggar tabeller utan RLS, policyer som släpper igenom varje rad och känsligt utseende kolumner som anonyma besökare kan läsa.
2. Konton skapade med någon annans adress. Med e-postbekräftelse av kan vem som helst registrera sig med en adress de inte äger.
3. Filer i publika buckets. En publik bucket serverar varje fil till alla med dess URL, och CDN:et cachar den över hela världen.
4. Biträden du lagt till själv. Varje e-post-, SMS-, AI- eller analystjänst som dina Edge Functions anropar är ditt biträde, inte Supabases, och behöver sitt eget avtal.
5. Radering och lagring. En raderingsbegäran misslyckas om främmande nycklar hindrar radering av en användare som skrivit innehåll, och loggar som behåller adresser för alltid är ett lagringsproblem.

De två sista, och fyra till, går jag igenom i GDPR-avsnittet i min säkerhetschecklista för Lovable-appar. För vad Supabase certifierar utöver GDPR, se är Supabase säkert?. Den här artikeln är inte juridisk rådgivning; ditt dataskyddsombud eller din jurist avgör vad din behandling kräver.