Alternativa apenas UE a Supabase.

Supabase is the open-source Firebase alternative: hosted Postgres + Auth + Storage + Edge Functions + Realtime with a polished developer experience. Supabase Inc. is a Delaware US corporation; the EU regions (Frankfurt, Ireland, London, Paris) run on AWS infrastructure under both Supabase and AWS US-jurisdictional control. The good news: Supabase is open-source. You can self-host the entire stack on EU infrastructure with full feature parity - that is the sovereign alternative we deploy for clients.

United States 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: United States
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

Supabase exits we have run come from one consistent trigger: a B2B SaaS that picked Supabase for its DX, grew to enterprise customers, and discovered that "Supabase Frankfurt on AWS Ireland" is two layers of US-jurisdictional processors that fail Schrems II analysis. The Supabase team itself has publicly discussed the data sovereignty constraints on their blog. Self-hosting Supabase on EU infrastructure preserves the full DX (the same supabase-js client works) while moving to full EU jurisdiction.

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.

Days 1-5

Self-hosted Supabase deployment

Deploy self-hosted Supabase stack on Binadit (Docker Compose or Kubernetes). Configure auth providers, storage backend, Edge Functions runtime. Set up monitoring and backups.
Days 6-14

Database + auth migration

Postgres dump+restore to self-hosted instance. User accounts migrated via auth provider data export. Storage buckets mirrored. Edge Functions redeployed.
Weeks 2-3

Application cutover

Application config updated to point at self-hosted Supabase URL. Same supabase-js client, same RLS policies, same auth flows. Cutover with a verification window.

Self-hosted Supabase on a single small VM replaces Supabase Pro at $25 per project per month plus per-project usage. For multi-project workloads, savings compound: a typical Supabase team plan ($599/month) becomes €40-100/month in raw infrastructure plus the managed-partner fee if you don't want to operate it yourself. Plus full EU jurisdiction.

Perguntas frequentes

Ver todas as perguntas frequentes

Is Supabase's EU region (Frankfurt, Ireland) sufficient for GDPR?

Residency yes, sovereignty no. Supabase Inc. is US-headquartered, and the Frankfurt/Ireland regions run on AWS - also US-jurisdictional. For Schrems II analyses, both layers are exposed.

Does self-hosted Supabase have full feature parity?

Yes for the core stack: Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. The supabase-js client works identically. The features that aren't in self-hosted: paid-tier features like team management UI and integrated logging dashboards (you build those with Loki + Grafana on EU infra).

How operationally complex is self-hosted Supabase?

For single-environment production, a single modest VM with Docker Compose is sufficient and operationally manageable for an experienced engineering team. For multi-environment or HA setups, Kubernetes with Helm chart is the production pattern; we operate this for clients.

Does the supabase-js client need code changes?

Just one: the URL points at your self-hosted instance instead of `*.supabase.co`. RLS policies, auth flows, storage URLs, realtime subscriptions - all unchanged.

What about managed Supabase EU equivalents?

There are emerging EU-headquartered offerings (Supascale, Supafast - both early-stage), but the production-ready answer is self-hosted Supabase managed by an EU partner. We deploy and operate this exact pattern.

How long does a Supabase exit take?

For a single-environment project (one Postgres, basic auth, a few buckets): 1-2 weeks elapsed. For multi-environment or large-data setups: 3-6 weeks. The migration is mechanically clean because everything is open-source upstream.

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