Alternativa apenas UE a Supabase.

Supabase é a alternativa open-source ao Firebase: Postgres alojado + Auth + Storage + Edge Functions + Realtime com uma experiência de developer bastante trabalhada. A Supabase Inc. é uma corporação dos EUA no Delaware; as regiões UE (Frankfurt, Ireland, London, Paris) correm em infraestrutura AWS sob controlo jurisdicional dos EUA tanto da Supabase como da AWS. A boa notícia: o Supabase é open-source. Pode fazer self-hosting da stack completa em infraestrutura UE com paridade total de funcionalidades - essa é a alternativa soberana que implementamos para clientes.

Estados Unidos Stack de substituição, apenas UE 10 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Supabase
Sede: San Francisco, CA
Jurisdição: Estados Unidos
Regime jurídico: CLOUD Act, FISA 702

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Supabase

As saídas do Supabase que já gerimos têm origem num gatilho consistente: um B2B SaaS que escolheu o Supabase pela sua DX, cresceu para clientes enterprise, e descobriu que "Supabase Frankfurt na AWS Ireland" são duas camadas de processadores sob jurisdição dos EUA que falham a análise Schrems II. A própria equipa do Supabase já discutiu publicamente as limitações de soberania de dados no seu blog. Fazer self-hosting do Supabase em infraestrutura UE preserva a DX completa (o mesmo cliente supabase-js funciona) ao mesmo tempo que se move para jurisdição UE total.

Supabase serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Supabase com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Supabase serviço	O que usamos no lugar	Nota de engenharia
Postgres (managed)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	A replicação em streaming permite-nos fazer a transição com segundos de downtime em vez de uma janela de manutenção, e as restaurações são testadas periodicamente em vez de assumidas.
Auth (GoTrue)	Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.	O GoTrue faz parte da stack open do Supabase; o self-hosting preserva a autenticação baseada em JWT com social logins, magic links e MFA.
Storage (S3-compatible)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	O Supabase Storage é uma camada de serviço sobre armazenamento compatível com S3; funciona com qualquer backend S3 europeu.
Edge Functions (Deno)	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	As Edge Functions são runtimes Deno; o equivalente self-hosted corre em qualquer plataforma de containers da UE.
Realtime (Postgres CDC)	Binadit Managed Cloud Platform. Replicação lógica de PostgreSQL para uma camada websocket, ou NATS para fan-out.	O Realtime é open-source; o self-hosting preserva o pub/sub baseado em WebSocket.
Vector embeddings (pgvector)	Binadit Managed Cloud Platform. pgvector no PostgreSQL, ou Qdrant para conjuntos de embeddings maiores.	Para cargas de trabalho vetoriais dedicadas, o Qdrant Cloud EU é uma alternativa soberana por padrão.
Studio (admin UI)	Binadit DevOps & Support. pgAdmin ou Metabase para acesso a dados, com Grafana para visões operacionais.	O Studio faz parte da distribuição self-hosted.
Database backups	Binadit Managed Cloud Platform. restic e pgBackRest para dados, Velero para o estado do Kubernetes, para storage isolado na UE.	WAL-G com backend de object storage na UE é o padrão de nível produção.
API (PostgREST)	Binadit Managed Cloud Platform. Traefik ou Kong, com rate limiting e OIDC na edge.	O PostgREST é open-source; o self-hosting preserva a geração de API REST.
CLI / Migrations	Binadit DevOps & Support. kubectl, Terraform e GitLab CI, com wrappers específicos do projeto onde fizerem sentido.	O Supabase CLI suporta `--db-url` para apontar para instâncias self-hosted.

Postgres (managed)

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia: A replicação em streaming permite-nos fazer a transição com segundos de downtime em vez de uma janela de manutenção, e as restaurações são testadas periodicamente em vez de assumidas.

Auth (GoTrue)

O que usamos no lugar: Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.
Nota de engenharia: O GoTrue faz parte da stack open do Supabase; o self-hosting preserva a autenticação baseada em JWT com social logins, magic links e MFA.

Storage (S3-compatible)

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: O Supabase Storage é uma camada de serviço sobre armazenamento compatível com S3; funciona com qualquer backend S3 europeu.

Edge Functions (Deno)

O que usamos no lugar: Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia: As Edge Functions são runtimes Deno; o equivalente self-hosted corre em qualquer plataforma de containers da UE.

Realtime (Postgres CDC)

O que usamos no lugar: Binadit Managed Cloud Platform. Replicação lógica de PostgreSQL para uma camada websocket, ou NATS para fan-out.
Nota de engenharia: O Realtime é open-source; o self-hosting preserva o pub/sub baseado em WebSocket.

Vector embeddings (pgvector)

O que usamos no lugar: Binadit Managed Cloud Platform. pgvector no PostgreSQL, ou Qdrant para conjuntos de embeddings maiores.
Nota de engenharia: Para cargas de trabalho vetoriais dedicadas, o Qdrant Cloud EU é uma alternativa soberana por padrão.

Studio (admin UI)

O que usamos no lugar: Binadit DevOps & Support. pgAdmin ou Metabase para acesso a dados, com Grafana para visões operacionais.
Nota de engenharia: O Studio faz parte da distribuição self-hosted.

Database backups

O que usamos no lugar: Binadit Managed Cloud Platform. restic e pgBackRest para dados, Velero para o estado do Kubernetes, para storage isolado na UE.
Nota de engenharia: WAL-G com backend de object storage na UE é o padrão de nível produção.

API (PostgREST)

O que usamos no lugar: Binadit Managed Cloud Platform. Traefik ou Kong, com rate limiting e OIDC na edge.
Nota de engenharia: O PostgREST é open-source; o self-hosting preserva a geração de API REST.

CLI / Migrations

O que usamos no lugar: Binadit DevOps & Support. kubectl, Terraform e GitLab CI, com wrappers específicos do projeto onde fizerem sentido.
Nota de engenharia: O Supabase CLI suporta `--db-url` para apontar para instâncias self-hosted.

Como migramos de Supabase

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

Dias 1-5

Implementação Supabase auto-hospedada

Fazer deploy da stack Supabase self-hosted na Binadit (Docker Compose ou Kubernetes). Configurar auth providers, storage backend, runtime de Edge Functions. Configurar monitoring e backups.
Dias 6-14

Migração de base de dados + autenticação

Dump+restore do Postgres para uma instância self-hosted. Contas de utilizador migradas via exportação de dados do fornecedor de autenticação. Buckets de armazenamento espelhados. Edge Functions reimplementadas.
Semanas 2-3

Cutover da aplicação

Configuração da aplicação atualizada para apontar para o URL do Supabase self-hosted. Mesmo cliente supabase-js, mesmas políticas RLS, mesmos fluxos de auth. Cutover com uma janela de verificação.

Uma implementação Supabase auto-hospedada numa única VM pequena substitui o Supabase Pro a $25 por projeto por mês, mais o uso por projeto. Para workloads com múltiplos projetos, as poupanças acumulam-se: um plano de equipa Supabase típico ($599/mês) passa a custar €40-100/mês em infraestrutura pura, mais a taxa do parceiro gestor caso não queira operá-la você mesmo. Além de jurisdição totalmente na UE.

Perguntas frequentes

Ver todas as perguntas frequentes

A região UE do Supabase (Frankfurt, Irlanda) é suficiente para o RGPD?

Residência sim, soberania não. A Supabase Inc. tem sede nos EUA, e as regiões de Frankfurt/Irlanda rodam na AWS - também sob jurisdição dos EUA. Para análises de Schrems II, ambas as camadas estão expostas.

O Supabase self-hosted tem paridade total de funcionalidades?

Sim para a stack principal: Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. O cliente supabase-js funciona de forma idêntica. As funcionalidades que não existem na versão autoalojada: funcionalidades de nível pago como a interface de gestão de equipas e dashboards de logging integrados (essas constroem-se com Loki + Grafana em infraestrutura da UE).

Quão complexo é operacionalmente o Supabase autoalojado?

Para produção com um único ambiente, uma VM modesta com Docker Compose é suficiente e operacionalmente gerível para uma equipa de engenharia experiente. Para configurações multi-ambiente ou de alta disponibilidade (HA), Kubernetes com Helm chart é o padrão de produção; nós operamos isto para clientes.

O cliente supabase-js precisa de alterações de código?

Apenas uma: o URL aponta para a sua instância self-hosted em vez de `*.supabase.co`. As políticas de RLS, fluxos de autenticação, URLs de storage, subscrições em tempo real - tudo permanece inalterado.

E quanto aos equivalentes de Supabase gerido na UE?

Existem ofertas emergentes sediadas na UE (Supascale, Supafast - ambas em fase inicial), mas a resposta pronta para produção é o Supabase self-hosted gerido por um parceiro na UE. Nós implementamos e operamos exatamente este padrão.

Quanto tempo demora uma saída do Supabase?

Para um projeto de ambiente único (um Postgres, autenticação básica, alguns buckets): 1-2 semanas decorridas. Para configurações multi-ambiente ou de dados de grande volume: 3-6 semanas. A migração é mecanicamente limpa porque tudo é open-source a montante.

Planeie a sua saída de Supabase.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor