O Supabase cumpre o RGPD? Onde estão mesmo os seus dados

Sou o Denys, engenheiro full-stack e de IA, e a maioria das apps que construo ou corrijo corre em Supabase. Os clientes europeus fazem duas perguntas antes de qualquer outra: o Supabase cumpre o RGPD e onde estão os dados? Este artigo responde às duas com os documentos do próprio Supabase e do Lovable, lidos a 29 de outubro de 2026, mais os comandos que uso para verificar um projeto.

O Supabase cumpre o RGPD?

O guia do RGPD do Supabase apresenta-o como uma responsabilidade partilhada: o Supabase protege a infraestrutura, e você é responsável pelo tratamento de dados da sua aplicação, pelos fluxos de consentimento e pelos controlos de acesso. Em termos de RGPD, o Supabase é o seu subcontratante para os dados que guarda, e o seu Data Processing Addendum é o contrato que o diz. O mesmo documento designa o Supabase responsável pelo tratamento para uma categoria, os dados de utilização que recolhe para operar a plataforma.

Duas partes desse DPA importam na prática:

• Região. Quando indica ao Supabase que trate os dados numa região, ele armazena-os e trata-os principalmente aí, salvo se a lei, as suas próprias instruções ou o serviço que pediu exigirem outra coisa.
• Subcontratantes ulteriores. Autoriza antecipadamente a lista de subcontratantes do Supabase, e o Supabase avisa com 30 dias de antecedência antes de a alterar. Pode subscrever essas alterações na mesma página. A lista inclui a AWS e a Cloudflare para alojamento, e prestadores de serviços para suporte, monitorização de erros e mensagens aos utilizadores da conta.

Onde é que o Supabase guarda os seus dados?

O FAQ de residência de dados e a página de regiões dividem-no assim:

Parte do seu projeto	Onde é tratada
Base de dados Postgres e as cópias	A região da AWS que escolheu
Auth (utilizadores, sessões)	A região que escolheu
Ficheiros do Storage na origem	A região que escolheu
Cache da CDN do Storage	A nível global, em cache na Cloudflare
Edge Functions	No edge mais próximo de quem chama, a menos que as fixe a uma região
Logs e telemetria da plataforma	Fora da sua região; os logs ficam em centros de dados da UE
Acesso do suporte	Uma equipa de suporte global, quando pede ajuda ou durante um incidente de segurança, registado
Dados da sua conta e de faturação	Sistemas centrais do Supabase; aqui o Supabase é o responsável pelo tratamento

O FAQ responde diretamente à pergunta crua: o Supabase não garante que os seus dados nunca saiam da região. A base de dados e as cópias ficam; as quatro categorias no fim da tabela podem sair.

Que regiões do Supabase estão na UE?

Quatro regiões concretas estão dentro da UE: West EU (Irlanda) eu-west-1, West EU (Paris) eu-west-3, Central EU (Frankfurt) eu-central-1 e North EU (Estocolmo) eu-north-1. Londres eu-west-2 e Zurique eu-central-2 ficam na Europa e têm decisões de adequação do RGPD, mas não são Estados-Membros da UE.

Essa distinção importa ao criar o projeto. A opção genérica “Europe” deixa o Supabase escolher uma região europeia disponível consoante a capacidade, e o guia de regiões avisa que pode ser Londres ou Zurique. Se o seu contrato ou o seu cliente diz “os dados ficam na UE”, escolha uma região concreta da UE. Mais um pormenor se usa Edge Functions regionais: a página de regiões diz que fixar uma função a uma região não está disponível em Ohio nem em Estocolmo.

Como verificar a região do seu projeto?

No painel, a região aparece nas definições do projeto. A partir de um terminal, a CLI do Supabase lista todos os projetos a que tem acesso com a sua região:

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

Executei-o na minha própria conta com a CLI 2.109.1: cada projeto devolveu o seu código de região da AWS, por isso uma vista rápida mostra se algum está fora da UE.

Pode alterá-la? Não. A nota de resolução de problemas do Supabase diz que um projeto fica preso à sua região ao nível da infraestrutura. Mudar significa criar um projeto novo na região de destino e migrar para ele, e depois atualizar o URL da API e as chaves na app e copiar à mão os segredos do início de sessão de terceiros. Transferir um projeto para outra organização também não altera a região.

O Lovable Cloud cumpre o RGPD?

Uma app Lovable Cloud corre o seu backend sobre o mesmo modelo, por isso aplicam-se as mesmas perguntas, com as definições do Lovable pela frente. Segundo a documentação do backend, a documentação da base de dados e a página do DPA do Lovable:

• A região é uma de Americas, Europe ou Asia Pacific, escolhida ao ativar o backend. Um valor por omissão do espaço de trabalho definido por um administrador prevalece (planos Business e Enterprise). Caso contrário, o Lovable usa a sua própria definição “where project data is stored” e, sem ela, a região mais próxima de si.
• Pode nunca a ver. Com Enable Cloud em “Always allow”, o Lovable cria o backend nessa região sem perguntar. Só “Ask each time” mostra a região primeiro.
• Não pode ser alterada. O Lovable diz claramente que a região de um projeto não pode ser alterada e que um projeto existente não pode ser movido.
• Verifique-a em More → Database → Manage → Settings, na linha Database location, por exemplo “Europe (Frankfurt)”.
• O site em si é servido globalmente, seja qual for a região; a região cobre apenas o backend.
• Os pedidos de IA são à parte. Manter na UE os pedidos a modelos de IA é uma definição chamada EU inference, nos espaços de trabalho Enterprise.
• O DPA está incluído nos planos Business e Enterprise.

Assim, se ativou o backend a trabalhar de fora da Europa, sem definição própria, o backend pode estar noutra região, e com “Always allow” ligado o Lovable não pergunta. Verifique a linha Database location antes de o seu primeiro utilizador real se registar.

O que a região não resolve

O próprio guia do Supabase di-lo: escolher uma região é um controlo de localização dos dados e não torna, por si só, uma aplicação conforme com o RGPD. As falhas que encontro com mais frequência estão na app, não na plataforma:

1. Dados pessoais legíveis por qualquer pessoa. Uma tabela com RLS desligado, ou com uma política que permite todas as linhas, serve nomes e emails a quem tenha a chave pública. O verificador de segurança do Supabase gratuito assinala tabelas sem RLS, políticas que permitem todas as linhas e colunas com ar sensível legíveis por visitantes anónimos.
2. Contas criadas com o endereço de outra pessoa. Com a confirmação de email desligada, qualquer pessoa pode registar-se com um endereço que não é seu.
3. Ficheiros em buckets públicos. Um bucket público serve cada ficheiro a quem tenha o seu URL, e a CDN guarda-o em cache em todo o mundo.
4. Subcontratantes que adicionou você. Cada serviço de email, SMS, IA ou análise que as suas Edge Functions chamam é o seu subcontratante, não o do Supabase, e precisa de contrato próprio.
5. Eliminação e conservação. Um pedido de apagamento falha se as chaves estrangeiras impedirem apagar um utilizador que escreveu conteúdo, e logs que guardam endereços para sempre são um problema de conservação.

Percorro os dois últimos, e mais quatro, na secção de RGPD da minha lista de segurança para apps Lovable. Para saber o que o Supabase certifica além do RGPD, veja o Supabase é seguro?. Este artigo não é aconselhamento jurídico; o seu encarregado de proteção de dados ou o seu advogado decide o que o seu tratamento exige.