Alternative UE-uniquement à Supabase.

Supabase est l'alternative open-source à Firebase : Postgres hébergé + Auth + Storage + Edge Functions + Realtime avec une expérience développeur soignée. Supabase Inc. est une société américaine du Delaware ; les régions UE (Francfort, Irlande, Londres, Paris) fonctionnent sur une infrastructure AWS sous le contrôle juridictionnel américain conjoint de Supabase et d'AWS. La bonne nouvelle : Supabase est open-source. Vous pouvez auto-héberger l'intégralité de la pile sur une infrastructure UE avec une parité complète des fonctionnalités - c'est l'alternative souveraine que nous déployons pour nos clients.

États-Unis 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
États-Unis
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

Les sorties de Supabase que nous avons gérées proviennent toutes d'un même déclencheur : un SaaS B2B qui a choisi Supabase pour son expérience développeur, a grandi jusqu'à avoir des clients entreprise, et a découvert que « Supabase Francfort sur AWS Irlande » représente deux couches de sous-traitants sous juridiction américaine qui échouent à l'analyse Schrems II. L'équipe Supabase elle-même a publiquement évoqué les contraintes de souveraineté des données sur son blog. L'auto-hébergement de Supabase sur une infrastructure UE préserve l'expérience développeur complète (le même client supabase-js fonctionne) tout en passant à une juridiction UE complète.

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.

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.

  1. Jours 1-5

    Déploiement Supabase autohébergé

    Déployer une stack Supabase auto-hébergée sur Binadit (Docker Compose ou Kubernetes). Configurer les fournisseurs d'authentification, le backend de stockage, le runtime Edge Functions. Mettre en place le monitoring et les backups.

  2. Jours 6-14

    Base de données + migration de l'authentification

    Dump+restauration Postgres vers une instance auto-hébergée. Comptes utilisateurs migrés via l'export de données du fournisseur d'authentification. Buckets de stockage répliqués en miroir. Edge Functions redéployées.

  3. Semaines 2-3

    Bascule de l'application

    Configuration de l'application mise à jour pour pointer vers l'URL Supabase auto-hébergée. Même client supabase-js, mêmes politiques RLS, mêmes flux d'authentification. Bascule avec une fenêtre de vérification.

Un déploiement Supabase autohébergé sur une seule petite VM remplace Supabase Pro à 25 $ par projet par mois plus l'usage par projet. Pour les workloads multi-projets, les économies s'accumulent : un plan d'équipe Supabase typique (599 $/mois) devient 40-100 €/mois d'infrastructure brute, plus les frais du partenaire managé si vous ne souhaitez pas l'opérer vous-même. Avec en plus une juridiction UE complète.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

La région UE de Supabase (Francfort, Irlande) est-elle suffisante pour le RGPD ?
Résidence oui, souveraineté non. Supabase Inc. a son siège aux États-Unis, et les régions Frankfort/Irlande fonctionnent sur AWS - également sous juridiction américaine. Pour les analyses Schrems II, les deux couches sont exposées.
Supabase autohébergé offre-t-il une parité de fonctionnalités complète ?
Oui pour le socle principal : Postgres, Auth (GoTrue), Storage, Edge Functions, Realtime, Studio, PostgREST. Le client supabase-js fonctionne de manière identique. Les fonctionnalités absentes en auto-hébergé : les fonctionnalités payantes comme l'interface de gestion d'équipe et les tableaux de bord de journalisation intégrés (vous les construisez avec Loki + Grafana sur une infrastructure UE).
Quelle est la complexité opérationnelle d'un Supabase auto-hébergé ?
Pour une production mono-environnement, une seule VM modeste avec Docker Compose est suffisante et gérable en exploitation pour une équipe d'ingénierie expérimentée. Pour des configurations multi-environnements ou HA, Kubernetes avec Helm chart est le pattern de production ; nous opérons cela pour nos clients.
Le client supabase-js nécessite-t-il des modifications de code ?
Une seule chose : l'URL pointe vers votre instance auto-hébergée au lieu de `*.supabase.co`. Les politiques RLS, les flux d'authentification, les URL de stockage, les abonnements realtime - tout reste inchangé.
Qu'en est-il des équivalents Supabase EU managés ?
Il existe des offres émergentes basées au siège dans l'UE (Supascale, Supafast - toutes deux en phase précoce), mais la réponse prête pour la production est un Supabase auto-hébergé géré par un partenaire UE. Nous déployons et exploitons exactement ce schéma.
Combien de temps dure une sortie de Supabase ?
Pour un projet à environnement unique (un Postgres, authentification basique, quelques buckets) : 1 à 2 semaines. Pour des configurations multi-environnements ou avec un gros volume de données : 3 à 6 semaines. La migration est mécaniquement propre car tout repose sur des briques open-source en amont.

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