Alternative UE-uniquement à 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 remplacement, UE uniquement 10 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: Supabase
Siège: San Francisco, CA
Juridiction: United States
Régime juridique: CLOUD Act, FISA 702

Une "région UE" n'est pas la souveraineté. Quatre questions tranchent.

La résidence des données indique où se trouvent les bits. La souveraineté indique quel système juridique peut en imposer l'accès. La réponse doit tenir sur les quatre points, sinon la stack n'est pas souveraine.

Résidence

Où les données sont-elles physiquement stockées ?

Pas "dans le cloud" : quel centre de données, dans quel pays, sous quelle juridiction.

Sous-traitants

Qui d'autre est dans votre chemin de données ?

Chaque fournisseur qui touche les données : le CDN, le relais e-mail, le tracker d'erreurs, le pipeline analytics.

Juridiction

Quelles lois peuvent contraindre à la divulgation ?

Un fournisseur dont le siège est aux États-Unis relève de la FISA 702 et du CLOUD Act, même si les données se trouvent à Francfort.

Garde des clés

Qui détient réellement les clés de chiffrement ?

Si le fournisseur cloud détient à la fois les données et les clés, il peut les lire, quel que soit le DPA.

Échoue AWS · Azure · GCP · Région UE

Échoue sur la juridiction et la garde des clés.

Bits en UE, maison mère américaine, sous-traitants américains dans le chemin par défaut, clés gérées par le fournisseur.

Réussit Stack géré par Binadit

Réussit sur les quatre.

Hébergé en UE sur une infrastructure au siège européen. Zéro sous-traitant américain dans le chemin par défaut. Clés détenues par le client ou par un KMS européen. Nommés dans votre DPA Article 28.

Pourquoi les équipes partent 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 services et leurs équivalents UE-uniquement

Une migration n'est pas "échanger une boîte contre une autre". La cartographie ci-dessous est ce que nous exécutons pour les clients qui quittent Supabase au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

Supabase service	Ce que nous utilisons à la place	Note d'ingénierie
Postgres (managed)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.	La réplication en streaming permet de basculer avec quelques secondes d'interruption plutôt qu'une fenêtre de maintenance, et les restaurations sont testées régulièrement plutôt que présumées fonctionnelles.
Auth (GoTrue)	Binadit Managed Cloud Platform. Keycloak ou Authentik comme fournisseur d'identité, avec OIDC et SAML.	GoTrue fait partie de la stack ouverte de Supabase ; l'auto-hébergement préserve l'authentification basée sur JWT avec connexions sociales, magic links et MFA.
Storage (S3-compatible)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.	Supabase Storage est une couche de service au-dessus d'un stockage compatible S3 ; fonctionne avec n'importe quel backend S3 EU.
Edge Functions (Deno)	Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.	Les Edge Functions sont des runtimes Deno ; l'équivalent auto-hébergé fonctionne sur n'importe quelle plateforme de conteneurs européenne.
Realtime (Postgres CDC)	Binadit Managed Cloud Platform. Réplication logique PostgreSQL vers une couche websocket, ou NATS pour le fan-out.	Realtime est open-source ; le self-hosting préserve le pub/sub basé sur WebSocket.
Vector embeddings (pgvector)	Binadit Managed Cloud Platform. pgvector sur PostgreSQL, ou Qdrant pour des ensembles d'embeddings plus volumineux.	Pour les charges de travail vectorielles dédiées, Qdrant Cloud EU est une alternative souveraine par défaut.
Studio (admin UI)	Binadit DevOps & Support. pgAdmin ou Metabase pour l'accès aux données, avec Grafana pour les vues opérationnelles.	Studio fait partie de la distribution self-hosted.
Database backups	Binadit Managed Cloud Platform. restic et pgBackRest pour les données, Velero pour l'état Kubernetes, vers un stockage UE isolé.	WAL-G avec un backend de stockage objet situé dans l'UE est le pattern de niveau production.
API (PostgREST)	Binadit Managed Cloud Platform. Traefik ou Kong, avec rate limiting et OIDC en périphérie.	PostgREST est open-source ; le self-hosting préserve la génération d'API REST.
CLI / Migrations	Binadit DevOps & Support. kubectl, Terraform et GitLab CI, avec des wrappers spécifiques au projet lorsqu'ils sont utiles.	Le CLI Supabase prend en charge `--db-url` pour cibler des instances self-hosted.

Postgres (managed)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.
Note d'ingénierie: La réplication en streaming permet de basculer avec quelques secondes d'interruption plutôt qu'une fenêtre de maintenance, et les restaurations sont testées régulièrement plutôt que présumées fonctionnelles.

Auth (GoTrue)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Keycloak ou Authentik comme fournisseur d'identité, avec OIDC et SAML.
Note d'ingénierie: GoTrue fait partie de la stack ouverte de Supabase ; l'auto-hébergement préserve l'authentification basée sur JWT avec connexions sociales, magic links et MFA.

Storage (S3-compatible)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.
Note d'ingénierie: Supabase Storage est une couche de service au-dessus d'un stockage compatible S3 ; fonctionne avec n'importe quel backend S3 EU.

Edge Functions (Deno)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.
Note d'ingénierie: Les Edge Functions sont des runtimes Deno ; l'équivalent auto-hébergé fonctionne sur n'importe quelle plateforme de conteneurs européenne.

Realtime (Postgres CDC)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Réplication logique PostgreSQL vers une couche websocket, ou NATS pour le fan-out.
Note d'ingénierie: Realtime est open-source ; le self-hosting préserve le pub/sub basé sur WebSocket.

Vector embeddings (pgvector)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. pgvector sur PostgreSQL, ou Qdrant pour des ensembles d'embeddings plus volumineux.
Note d'ingénierie: Pour les charges de travail vectorielles dédiées, Qdrant Cloud EU est une alternative souveraine par défaut.

Studio (admin UI)

Ce que nous utilisons à la place: Binadit DevOps & Support. pgAdmin ou Metabase pour l'accès aux données, avec Grafana pour les vues opérationnelles.
Note d'ingénierie: Studio fait partie de la distribution self-hosted.

Database backups

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. restic et pgBackRest pour les données, Velero pour l'état Kubernetes, vers un stockage UE isolé.
Note d'ingénierie: WAL-G avec un backend de stockage objet situé dans l'UE est le pattern de niveau production.

API (PostgREST)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Traefik ou Kong, avec rate limiting et OIDC en périphérie.
Note d'ingénierie: PostgREST est open-source ; le self-hosting préserve la génération d'API REST.

CLI / Migrations

Ce que nous utilisons à la place: Binadit DevOps & Support. kubectl, Terraform et GitLab CI, avec des wrappers spécifiques au projet lorsqu'ils sont utiles.
Note d'ingénierie: Le CLI Supabase prend en charge `--db-url` pour cibler des instances self-hosted.

Comment nous migrons depuis Supabase

Une migration typique de mid-market se déroule en trois phases. Les chiffres ci-dessous supposent une équipe d'ingénierie de 6 à 10 personnes et une stack applicative modérément complexe.

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.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

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.

Planifiez votre sortie de Supabase.

Appel de cadrage de 30 minutes. Nous cartographions votre stack par rapport aux alternatives UE-uniquement, estimons l'effort de migration et vous disons si c'est le bon choix.

Planifier un appel Comparer un autre fournisseur