Alternativa solo UE a Supabase.

Supabase è l'alternativa open-source a Firebase: Postgres hosted + Auth + Storage + Edge Functions + Realtime con un'esperienza sviluppatore raffinata. Supabase Inc. è una corporation US del Delaware; le regioni EU (Francoforte, Irlanda, Londra, Parigi) girano su infrastruttura AWS sotto il controllo giurisdizionale US sia di Supabase che di AWS. La buona notizia: Supabase è open-source. Puoi fare self-hosting dell'intero stack su infrastruttura EU con piena parità di funzionalità - questa è l'alternativa sovrana che deployiamo per i clienti.

Stati Uniti Stack sostitutivo, solo UE 10 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: Supabase
Sede: San Francisco, CA
Giurisdizione: Stati Uniti
Regime giuridico: CLOUD Act, FISA 702

"Regione UE" non è sovranità. Quattro domande decidono.

La residenza dei dati dice dove si trovano i bit. La sovranità dice quale sistema giuridico può imporne l'accesso. La risposta deve reggere su tutti e quattro i punti, altrimenti lo stack non è sovrano.

Residenza

Dove sono fisicamente archiviati i dati?

Non "nel cloud": quale datacenter, in quale paese, sotto quale giurisdizione.

Sub-responsabili

Chi altro è nel suo percorso dei dati?

Ogni fornitore che tocca i dati: il CDN, il relay e-mail, il tracker degli errori, la pipeline di analytics.

Giurisdizione

Quali leggi possono imporre la divulgazione?

Un fornitore con sede negli Stati Uniti ricade sotto FISA 702 e CLOUD Act, anche se i bit si trovano a Francoforte.

Custodia delle chiavi

Chi detiene effettivamente le chiavi di cifratura?

Se il provider cloud detiene sia i dati sia le chiavi, può leggerli, indipendentemente da qualsiasi DPA.

Non supera AWS · Azure · GCP · Regione UE

Fallisce su giurisdizione e custodia delle chiavi.

Bit nell'UE, casa madre statunitense, sub-responsabili americani nel percorso predefinito, chiavi gestite dal fornitore.

Supera Stack gestito da Binadit

Passa su tutte e quattro.

Ospitato in UE su infrastruttura con sede europea. Zero sub-responsabili statunitensi nel percorso predefinito. Chiavi del cliente o di KMS europeo. Elencati per nome nel suo DPA Articolo 28.

Perché i team se ne vanno Supabase

Le uscite da Supabase che abbiamo gestito derivano da un trigger costante: un B2B SaaS che ha scelto Supabase per la sua DX, è cresciuto fino ad avere clienti enterprise, e ha scoperto che "Supabase Frankfurt su AWS Irlanda" sono due livelli di processori sotto giurisdizione US che falliscono l'analisi Schrems II. Il team di Supabase stesso ha discusso pubblicamente i vincoli di sovranità dei dati sul proprio blog. Il self-hosting di Supabase su infrastruttura EU preserva l'intera DX (lo stesso client supabase-js funziona) passando a piena giurisdizione EU.

Supabase servizi e i loro equivalenti solo UE

Una migrazione non è "scambiare una scatola con un'altra". La mappatura sottostante è ciò che eseguiamo per i clienti che lasciano Supabase in base a Schrems II: piena giurisdizione UE, nessuna capogruppo statunitense nel percorso dei dati.

Supabase servizio	Cosa usiamo al suo posto	Nota di ingegneria
Postgres (managed)	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.	La replica in streaming ci permette di effettuare il cutover con pochi secondi di downtime invece di una finestra di manutenzione, e i ripristini vengono testati secondo una pianificazione invece di essere dati per scontati.
Auth (GoTrue)	Binadit Managed Cloud Platform. Keycloak o Authentik come identity provider, con OIDC e SAML.	GoTrue fa parte dello stack open Supabase; il self-hosting preserva l'autenticazione basata su JWT con social login, magic link, MFA.
Storage (S3-compatible)	Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.	Supabase Storage è un livello di servizio sopra uno storage compatibile S3; funziona con qualsiasi backend S3 EU.
Edge Functions (Deno)	Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.	Le Edge Functions sono runtime Deno; l'equivalente self-hosted funziona su qualsiasi piattaforma container UE.
Realtime (Postgres CDC)	Binadit Managed Cloud Platform. Replica logica PostgreSQL verso un layer websocket, o NATS per il fan-out.	Realtime è open-source; il self-hosting preserva il pub/sub basato su WebSocket.
Vector embeddings (pgvector)	Binadit Managed Cloud Platform. pgvector su PostgreSQL, oppure Qdrant per set di embedding più grandi.	Per workload vettoriali dedicati, Qdrant Cloud EU è un'alternativa sovrana by default.
Studio (admin UI)	Binadit DevOps & Support. pgAdmin o Metabase per l'accesso ai dati, con Grafana per le viste operative.	Studio fa parte della distribuzione self-hosted.
Database backups	Binadit Managed Cloud Platform. restic e pgBackRest per i dati, Velero per lo stato di Kubernetes, su storage EU isolato.	WAL-G con backend di object storage EU è il pattern adatto alla produzione.
API (PostgREST)	Binadit Managed Cloud Platform. Traefik o Kong, con rate limiting e OIDC all'edge.	PostgREST è open-source; il self-hosting preserva la generazione dell'API REST.
CLI / Migrations	Binadit DevOps & Support. kubectl, Terraform e GitLab CI, con wrapper specifici per progetto dove utili.	La CLI di Supabase supporta `--db-url` per puntare a istanze self-hosted.

Postgres (managed)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.
Nota di ingegneria: La replica in streaming ci permette di effettuare il cutover con pochi secondi di downtime invece di una finestra di manutenzione, e i ripristini vengono testati secondo una pianificazione invece di essere dati per scontati.

Auth (GoTrue)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Keycloak o Authentik come identity provider, con OIDC e SAML.
Nota di ingegneria: GoTrue fa parte dello stack open Supabase; il self-hosting preserva l'autenticazione basata su JWT con social login, magic link, MFA.

Storage (S3-compatible)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.
Nota di ingegneria: Supabase Storage è un livello di servizio sopra uno storage compatibile S3; funziona con qualsiasi backend S3 EU.

Edge Functions (Deno)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.
Nota di ingegneria: Le Edge Functions sono runtime Deno; l'equivalente self-hosted funziona su qualsiasi piattaforma container UE.

Realtime (Postgres CDC)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Replica logica PostgreSQL verso un layer websocket, o NATS per il fan-out.
Nota di ingegneria: Realtime è open-source; il self-hosting preserva il pub/sub basato su WebSocket.

Vector embeddings (pgvector)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. pgvector su PostgreSQL, oppure Qdrant per set di embedding più grandi.
Nota di ingegneria: Per workload vettoriali dedicati, Qdrant Cloud EU è un'alternativa sovrana by default.

Studio (admin UI)

Cosa usiamo al suo posto: Binadit DevOps & Support. pgAdmin o Metabase per l'accesso ai dati, con Grafana per le viste operative.
Nota di ingegneria: Studio fa parte della distribuzione self-hosted.

Database backups

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. restic e pgBackRest per i dati, Velero per lo stato di Kubernetes, su storage EU isolato.
Nota di ingegneria: WAL-G con backend di object storage EU è il pattern adatto alla produzione.

API (PostgREST)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Traefik o Kong, con rate limiting e OIDC all'edge.
Nota di ingegneria: PostgREST è open-source; il self-hosting preserva la generazione dell'API REST.

CLI / Migrations

Cosa usiamo al suo posto: Binadit DevOps & Support. kubectl, Terraform e GitLab CI, con wrapper specifici per progetto dove utili.
Nota di ingegneria: La CLI di Supabase supporta `--db-url` per puntare a istanze self-hosted.

Come migriamo da Supabase

Una tipica migrazione di mid-market si svolge in tre fasi. I numeri qui sotto assumono un team di ingegneria di 6-10 persone e uno stack applicativo moderatamente complesso.

Giorni 1-5

Deployment self-hosted di Supabase

Deploy dello stack Supabase self-hosted su Binadit (Docker Compose o Kubernetes). Configurazione dei provider di autenticazione, backend di storage, runtime Edge Functions. Impostazione di monitoring e backup.
Giorni 6-14

Database + migrazione autenticazione

Dump e restore di Postgres su istanza self-hosted. Account utente migrati tramite export dati del provider di autenticazione. Bucket di storage mirrorati. Edge Functions ridistribuite.
Settimane 2-3

Cutover dell'applicazione

Configurazione dell'applicazione aggiornata per puntare all'URL Supabase self-hosted. Stesso client supabase-js, stesse policy RLS, stessi flussi di auth. Cutover con una finestra di verifica.

Un deployment self-hosted di Supabase su una singola VM di piccole dimensioni sostituisce Supabase Pro a 25$ per progetto al mese più i costi di utilizzo per progetto. Per workload multi-progetto, i risparmi si moltiplicano: un tipico piano team di Supabase (599$/mese) diventa 40-100€/mese di sola infrastruttura, più la fee del partner gestito se non si vuole operarlo autonomamente. In più, piena giurisdizione EU.

Domande frequenti

Visualizza tutte le domande frequenti

La region EU di Supabase (Francoforte, Irlanda) è sufficiente per il GDPR?

Residenza sì, sovranità no. Supabase Inc. ha sede negli Stati Uniti, e le regioni Frankfurt/Ireland girano su AWS - anch'esso di giurisdizione statunitense. Per le analisi Schrems II, entrambi i livelli sono esposti.

Supabase self-hosted ha piena parità di funzionalità?

Sì per lo stack principale: Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. Il client supabase-js funziona in modo identico. Le funzionalità non presenti nella versione self-hosted: funzionalità a pagamento come l'UI di team management e le dashboard di logging integrate (queste si costruiscono con Loki + Grafana su infrastruttura EU).

Quanto è complesso a livello operativo Supabase self-hosted?

Per la produzione a singolo ambiente, una singola VM di dimensioni modeste con Docker Compose è sufficiente e gestibile operativamente per un team di ingegneria esperto. Per configurazioni multi-ambiente o HA, Kubernetes con Helm chart è il pattern di produzione; lo gestiamo per i nostri clienti.

Il client supabase-js richiede modifiche al codice?

Solo una: l'URL punta alla tua istanza self-hosted invece che a `*.supabase.co`. Le policy RLS, i flussi di auth, gli URL di storage, le sottoscrizioni realtime - tutto invariato.

E per quanto riguarda gli equivalenti EU di Supabase gestito?

Esistono offerte emergenti con sede in UE (Supascale, Supafast - entrambe in fase iniziale), ma la soluzione pronta per la produzione è Supabase self-hosted gestito da un partner UE. Distribuiamo e gestiamo esattamente questo schema.

Quanto tempo richiede un'uscita da Supabase?

Per un progetto a singolo ambiente (un Postgres, autenticazione di base, alcuni bucket): 1-2 settimane. Per configurazioni multi-ambiente o con grandi volumi di dati: 3-6 settimane. La migrazione è meccanicamente pulita perché tutto è open-source a monte.

Pianifica la tua uscita da Supabase.

Chiamata di scoping di 30 minuti. Mappiamo il tuo stack rispetto alle alternative solo UE, stimiamo lo sforzo di migrazione e ti diciamo se è la scelta giusta.

Prenota una chiamata Confronta un altro provider