Tu pètes des fuses chaque mois quand la facture cloud arrive avec une ligne « Data Transfer Out » qui a doublé. C’est normal : les grandes plateformes cloud ont bâti un modèle où sortir tes données te coûte cher, et rentrer dans leur écosystème propriétaire coûte encore plus cher à long terme. UpCloud + Supabase en self-hosted, c’est une réponse directe à ce problème. Zéro frais d’egress côté UpCloud, Postgres open-source côté Supabase, Kubernetes managé pour le liant. Pas une solution magique, mais une combinaison sérieuse pour les équipes qui ont la capacité opérationnelle d’en tirer profit. Ce que tu vas apprendre :
- Pourquoi Firebase crée une dépendance difficile à quitter, et comment Supabase en diffère structurellement
- Ce que « zéro frais d’egress » signifie concrètement pour ton budget à volume élevé
- Comment Kubernetes managé sur UpCloud change l’équation opérationnelle
- Les cas où la souveraineté des données régionale devient non-négociable
- Pour qui cette combinaison a du sens, et pour qui elle est franchement overkill
Supabase et UpCloud : de quoi parle-t-on exactement
Supabase a été fondé en 2020 par Paul Copplestone et Ant Wilson, et est passé par Y Combinator W21. L’idée centrale : bâtir une alternative open-source à Firebase en mettant Postgres au centre plutôt qu’une base de données propriétaire. Supabase est publié sous licence Apache 2.0, ce qui veut dire que tu peux le déployer toi-même, l’auditer, le forker si tu veux. Leur offre cloud gérée démarre à zéro avec un plan Free, monte à 25 $US/mois pour le plan Pro qui inclut 8 GB de base de données, et atteint 599 $US/mois pour le plan Team. Il y a aussi un plan Enterprise avec tarification sur mesure. Pour les équipes qui veulent un contrôle total, il y a l’option self-hosted.
UpCloud, c’est différent. C’est un fournisseur cloud finlandais avec des datacentres en Europe, en Amérique du Nord et en Asie. Leur proposition principale : infrastructure cloud à haute performance avec une politique de zéro frais de sortie de données (egress). Ils offrent aussi un service Kubernetes managé (UKS, pour UpCloud Kubernetes Service). Les nouveaux comptes reçoivent 500 $ en crédits gratuits pour démarrer. Le support client est disponible 24/7. La combinaison des deux : tu déploies Supabase sur le Kubernetes managé d’UpCloud. Tu gardes le contrôle total sur où vivent tes données, tu choisis ta région, et tu ne paies pas pour sortir des données de la plateforme.
Le problème concret du vendor lock-in avec Firebase
Firebase, c’est Google. Et Google a construit un écosystème où chaque brique que tu utilises te rend un peu plus dépendant de la suivante. Firestore, Firebase Auth, Firebase Storage, Firebase Functions : chacun a une API propriétaire, un modèle de données spécifique, un comportement particulier en termes de transactions et de requêtes. Le vrai problème n’est pas d’entrer dans Firebase. C’est d’en sortir. Quand ton app est construite sur Firestore, la migration vers Postgres n’est pas juste un changement de driver de base de données. C’est une réécriture partielle de ta couche d’accès aux données, parce que le modèle document de Firestore et le modèle relationnel de Postgres sont fondamentalement différents. Tes requêtes ne se transfèrent pas.
Il y a aussi la question des coûts à l’échelle. Firebase facture par opération, par lecture, par écriture, par stockage. Quand tu es petit, c’est quasi-invisible. Quand tu grossis, ces unités de facturation peuvent créer des surprises désagréables, surtout si ton modèle d’accès aux données n’était pas optimisé pour minimiser les lectures Firestore.
Supabase, lui, est bâti sur Postgres. Postgres existe depuis 1996, il y a des décennies de documentation, d’outils, de connaissance collective. Migrer de Supabase vers n’importe quelle autre solution Postgres, c’est un pg_dump. Ce n’est pas trivial à grande échelle, mais c’est une opération standard avec des outils établis. La migration est prévisible.
À la Taverne, on fait la différence entre « difficile à quitter » parce que le produit est bon, et « difficile à quitter » parce que la sortie est conçue pour être coûteuse. Firebase, c’est souvent la deuxième catégorie.
Ce qu’UpCloud apporte techniquement à Supabase
Le Kubernetes managé d’UpCloud (UKS) gère le control plane pour toi. Tu déploies tes worker nodes, tu configures tes namespaces, mais tu n’as pas à t’occuper de la haute disponibilité des composants Kubernetes eux-mêmes. C’est le niveau d’abstraction habituel d’un service Kubernetes managé : similaire à ce qu’offrent EKS sur AWS ou GKE sur Google Cloud, mais avec la politique de frais d’egress zéro d’UpCloud. Pour Supabase en self-hosted, Kubernetes a du sens parce que Supabase n’est pas un seul binaire. C’est un ensemble de services : le serveur Postgres, PostgREST (pour l’API REST auto-générée), GoTrue (pour l’authentification), Realtime (pour les websockets), Storage API, Kong (pour le gateway). Kubernetes te donne des outils naturels pour orchestrer ces composants, les scaler indépendamment, et gérer les mises à jour.
UpCloud offre aussi du stockage en bloc attachable aux pods et une offre de base de données managée si tu veux externaliser Postgres lui-même plutôt que le faire tourner dans un pod. Cette flexibilité compte : tu peux choisir jusqu’où tu veux descendre dans la gestion manuelle. Ce qui change concrètement : les datacentres UpCloud en Europe te permettent de localiser tes données précisément. Helsinki, Francfort, Amsterdam. Pour les équipes soumises au RGPD qui doivent démontrer que leurs données ne quittent pas l’UE, c’est un argument opérationnel direct, pas juste marketing.
Zéro frais d’egress : ce que ça représente en chiffres réels
Soyons clairs sur ce que « zéro frais d’egress » veut dire : UpCloud ne facture pas les transferts de données sortants de ses datacentres vers internet. Sur AWS, GCP ou Azure, ces coûts s’accumulent à chaque gigaoctet qui quitte leurs serveurs.
Pour des applications avec du trafic bas à modéré, la différence est marginale. Mais pour certains profils d’usage, ça change l’équation. Si tu as une app qui sert beaucoup de médias, de fichiers volumineux, ou qui fait du streaming de données vers des clients externes, les coûts d’egress chez les grands cloud peuvent représenter une portion significative de ta facture mensuelle.
La nuance importante : l’absence de frais d’egress ne signifie pas que UpCloud est nécessairement moins cher au total. Tu paies pour tes instances de compute, ton stockage, ton réseau interne. Le coût total réel dépend de ton volume de données, de ton trafic, et des ressources Kubernetes que tu alloues. Si tu as une app légère avec peu de transferts sortants, l’avantage d’egress zéro est quasi-nul. Si tu as un volume sortant substantiel, la différence peut être significative.
L’egress zéro est un avantage réel, mais ce n’est pas un chèque en blanc. Fais ton calcul avec tes chiffres, pas les leurs.
Kubernetes managé sur UpCloud : avantages et limites pratiques
Le premier avantage d’UKS, c’est la simplicité relative du control plane. Tu n’as pas à gérer etcd, le scheduler, les API servers Kubernetes. UpCloud s’en occupe. Tu te concentres sur tes workloads. Le second avantage : les intégrations réseau. UpCloud’s SDN (software-defined networking) est bien intégré avec UKS, ce qui simplifie la configuration des load balancers et des IPs publiques pour exposer tes services Supabase. Le service d’object storage d’UpCloud peut remplacer S3 pour le stockage des fichiers Supabase, ce qui garde tout dans le même écosystème et élimine les transferts inter-cloud.
Les limites, maintenant, parce qu’il y en a.
Kubernetes, même managé, demande de la connaissance opérationnelle. Configurer correctement les PersistentVolumeClaims pour Postgres, gérer les StatefulSets, mettre en place un monitoring sérieux avec Prometheus et Grafana, configurer les backup automatiques : tout ça prend du temps et de l’expertise. Si ton équipe n’a pas un profil DevOps ou SRE, ou si tu n’as pas le budget pour en avoir un, cette complexité va te coûter plus que ce que tu économises en egress.
Il y a aussi la question des mises à jour Supabase. Sur Supabase Cloud, les mises à jour sont automatiques. En self-hosted, tu gères les upgrades toi-même. Ça inclut les migrations de base de données, les changements de configuration entre versions, les dépréciations d’API. Ce n’est pas insurmontable, mais c’est un travail récurrent qui a un coût en temps.
L’écosystème UpCloud est aussi plus petit que celui d’AWS ou GCP. Moins de ressources communautaires, moins de tutoriels spécifiques, moins d’intégrations tierces natives. Si tu tombes sur un problème obscur à 2h du matin, Stack Overflow aura beaucoup plus de réponses pour EKS que pour UKS. C’est une réalité à intégrer dans ta décision.
Souveraineté des données et conformité régionale : cas d’usage concrets
La conformité réglementaire, c’est souvent l’argument qui transforme une préférence technique en exigence non-négociable. Pour les équipes qui travaillent avec des données personnelles de résidents européens, le RGPD impose des contraintes précises sur où ces données peuvent être stockées et traitées. Sur Supabase Cloud, tu choisis une région au moment de créer ton projet. Supabase offre des régions en Europe (Francfort est la principale). C’est suffisant pour beaucoup d’usages. Mais tu fais confiance à Supabase pour maintenir cette isolation régionale, et tu n’as pas accès direct à l’infrastructure sous-jacente pour le démontrer à un auditeur.
En self-hosted sur UpCloud, tu sais exactement dans quel datacentre tourne ta base de données. Tu peux le documenter, l’auditer, le montrer à un DPO (délégué à la protection des données). Pour les startups en santé numérique, en fintech, ou dans le secteur public québécois ou européen, cette traçabilité directe a une valeur réelle. Il y a aussi des secteurs où la souveraineté des données va au-delà du RGPD. Certains contrats gouvernementaux spécifient que les données doivent rester sur des infrastructures hébergées dans une juridiction précise. Certaines industries réglementées ont des exigences similaires. Dans ces cas, self-hosted avec un fournisseur qui documente clairement sa localisation géographique n’est pas un luxe, c’est une condition du contrat.
| Aspect de conformité | Supabase Cloud | Supabase self-hosted sur UpCloud |
|---|---|---|
| Localisation garantie par région | Oui, par sélection de région | Oui, contrôle direct sur le datacentre |
| Accès auditeur à l'infrastructure | Non, couche d'abstraction Supabase | Oui, accès direct Kubernetes + UpCloud |
| Certification fournisseur (ISO, SOC2) | Via Supabase Cloud | Via UpCloud pour l'infra, responsabilité interne pour l'app |
| Mises à jour de sécurité | Automatiques côté Supabase Cloud | Manuelles, à la charge de ton équipe |
| Isolation des données multi-tenant | Gérée par Supabase | Gérée par ta configuration |
La nuance : être en self-hosted ne te donne pas automatiquement une meilleure posture de sécurité. Tu hérites aussi des responsabilités. La gestion des certificats TLS, le patching des images Docker, la configuration des network policies Kubernetes, l’isolation des secrets : tout ça devient ta responsabilité. La conformité n’est pas une case cochée par le simple fait de self-héberger.
Comparaison directe : Supabase Cloud vs Supabase sur UpCloud vs Firebase
Regardons les trois options côte à côte sur les axes qui comptent pour une décision réelle.
| Critère | Supabase Cloud (Pro) | Supabase self-hosted sur UpCloud | Firebase |
|---|---|---|---|
| Prix de départ | 25 $US/mois | Variable selon ressources UpCloud + 500 $ crédits gratuits | Gratuit avec quotas, puis variable |
| Frais d'egress | Via AWS/GCP selon région | Aucun (politique UpCloud) | Via Google Cloud (facturation par volume) |
| Base de données | Postgres managé par Supabase | Postgres géré par ton équipe | Firestore (NoSQL propriétaire) |
| Open-source / portabilité | Oui, migration pg_dump | Oui, contrôle total | Non, écosystème Google propriétaire |
| Effort opérationnel | Faible (Supabase gère) | Élevé (ton équipe gère Kubernetes) | Faible (Google gère) |
| Contrôle de la localisation | Choix de région Supabase | Contrôle direct datacentre UpCloud | Choix de région Google Cloud |
| Mises à jour | Automatiques | Manuelles | Automatiques |
| Support | Support Supabase par plan | Support UpCloud 24/7 + communauté Supabase | Support Google par plan |
Ce tableau révèle une logique claire : Supabase Cloud et Firebase sont des solutions « tu pousses le problème à quelqu’un d’autre ». En contrepartie, tu acceptes leur modèle de coûts et tu délègues le contrôle. Supabase self-hosted sur UpCloud, c’est l’option où tu reprends le contrôle, mais tu prends aussi le volant.
Firebase gagne sur la rapidité de démarrage et l’intégration native avec l’écosystème Google (Analytics, Crashlytics, AdMob). Si ton app est déjà profondément dans cet écosystème, c’est un avantage réel à ne pas ignorer. Supabase Cloud gagne sur l’équilibre : tu as Postgres, tu as l’open-source, tu as une API REST et realtime sans rien configurer, et tu n’as pas à gérer Kubernetes. Pour la plupart des équipes de moins de dix personnes sans DevOps dédié, c’est probablement le meilleur rapport valeur/effort. Supabase sur UpCloud gagne sur le contrôle et les coûts d’egress à volume élevé. Si tu as des contraintes de conformité régionale précises, un volume de données sortantes significatif, et une équipe capable de gérer l’infrastructure, le calcul commence à pencher dans ce sens.
Pour qui cette combinaison a du sens, et pour qui elle n’en a pas
Ça a du sens si : Tu as un profil DevOps ou SRE dans ton équipe (ou un freelance de confiance qui peut s’en occuper). Sans ça, tu vas passer plus de temps à déboguer Kubernetes qu’à construire ton produit. Tu as des contraintes de conformité réglementaire précises qui nécessitent un contrôle documenté de la localisation des données. Santé numérique, secteur public, fintech avec clients européens. Ton volume de données sortantes est suffisant pour que les frais d’egress représentent une portion non-négociable de ta facture mensuelle actuelle. À faible volume, l’avantage est marginal. Tu construis quelque chose à long terme et tu veux éviter un lock-in architectural. Avoir Postgres sous ta main complète, avec des backups que tu contrôles et une migration prévisible, a une valeur stratégique sur plusieurs années.
Ça n’a pas de sens si : Tu es une équipe de deux ou trois devs qui bossent sur un MVP. Kubernetes, c’est une couche de complexité que tu n’as pas besoin avant que le produit ait trouvé son marché. Commence sur Supabase Cloud, migre plus tard si tu en as besoin. Tu n’as pas envie de gérer les mises à jour, les backups, les certificats, et les incidents d’infrastructure le weekend. Ce n’est pas un jugement, c’est une réalité : self-hosted, ça veut dire que c’est toi qui te réveilles quand le pod Postgres crashe à 3h du matin. Ton app est déjà profondément intégrée dans Firebase avec des fonctionnalités difficiles à répliquer (Firebase ML, Remote Config complexe, Dynamic Links). Le coût de migration dépasse probablement les bénéfices de l’open-source dans ce cas. Tu cherches à économiser de l’argent sur un budget serré sans avoir l’expertise pour optimiser ton cluster Kubernetes. Un cluster mal dimensionné peut coûter plus cher que Supabase Cloud Pro, et tu auras en prime la complexité opérationnelle sans les économies.
Le test simple : est-ce que l’un des points suivants est vrai pour ton projet? Contrainte de conformité régionale, volume d’egress élevé, équipe avec capacité DevOps, ou horizon de cinq ans et plus sur la même architecture? Si aucun de ces points s’applique, Supabase Cloud te sert probablement mieux.
Comment démarrer : étapes concrètes pour déployer Supabase sur UpCloud
Voici la séquence logique. Pas un tutoriel step-by-step exhaustif (ça prendrait un article entier), mais les étapes critiques pour comprendre ce dans quoi tu t’engages. Étape 1 : Crée un compte UpCloud et active tes crédits UpCloud offre 500 $ en crédits gratuits à la création de compte. C’est suffisant pour expérimenter sérieusement. Tu actives UKS dans la console, tu choisis ta région (Helsinki et Francfort sont les options européennes principales), et tu provisionnes ton premier cluster.
Étape 2 : Dimensionne ton cluster Kubernetes
Supabase en self-hosted tourne plusieurs services simultanément. Il te faut au minimum des ressources suffisantes pour Postgres, PostgREST, GoTrue, Realtime, et Kong. Pour un environnement de développement ou une charge légère, un ou deux worker nodes suffisent. Pour la production, tu veux de la redondance : plusieurs nodes répartis sur des zones de disponibilité différentes, et un plan de backup Postgres documenté.
Ne sous-dimensionne pas Postgres. C’est le composant critique. Si ton pod Postgres manque de mémoire, tout tombe.
Étape 3 : Utilise les Helm charts officiels Supabase
Supabase maintient des Helm charts officiels pour le déploiement Kubernetes. C’est le point de départ recommandé. Les charts gèrent la création des services, les ConfigMaps, les Secrets, et les dépendances inter-services. Tu les configures via un fichier values.yaml où tu spécifies tes credentials Postgres, tes clés JWT, et les URLs de ton domaine.
Étape 4 : Configure le stockage avec UpCloud Object Storage
UpCloud offre un service de stockage objet compatible S3. Tu peux le connecter directement à Supabase Storage en configurant les variables d’environnement appropriées dans ton Helm values. Ça garde tes fichiers dans l’écosystème UpCloud, ce qui maintient la cohérence de ta politique d’egress zéro pour le stockage aussi.
Étape 5 : Mets en place le monitoring dès le départ
Ne reporte pas ça à plus tard. Prometheus et Grafana sont les outils standards pour le monitoring Kubernetes. Supabase expose des métriques dans un format compatible Prometheus. Configure des alertes sur l’utilisation CPU et mémoire de Postgres, sur la latence des requêtes, et sur l’espace disque disponible. Un cluster Kubernetes sans monitoring, c’est voler à l’aveugle.
Étape 6 : Documente ta stratégie de backup
Postgres offre pg_dump pour des backups logiques et pg_basebackup pour des backups physiques. UpCloud Object Storage est une destination naturelle pour ces backups. Configure des backups automatiques via un CronJob Kubernetes, teste tes restaurations régulièrement (un backup que tu n’as jamais restauré est un backup dont tu ne sais pas s’il fonctionne), et documente la procédure pour ton équipe.
Étape 7 : Valide ta configuration de conformité Si tu te déploies pour des raisons de conformité régionale, documente-le formellement. Capture la configuration de ton cluster (région, datacentre), le chemin des données de l’application jusqu’au stockage, et les politiques de réseau qui empêchent les données de sortir de la région désignée. C’est cette documentation que tu donneras à ton DPO ou à un auditeur.
Verdict : une option sérieuse pour les équipes qui ont la capacité
Supabase sur UpCloud, c’est une combinaison honnête. Elle résout des problèmes réels : les frais d’egress à volume élevé, le lock-in propriétaire de Firebase, et le besoin de contrôle documenté sur la localisation des données. Elle ne résout pas la complexité opérationnelle. Elle la déplace de chez ton fournisseur SaaS vers ton équipe. C’est un trade-off acceptable si ton équipe a l’expertise pour le gérer, et un fardeau si elle ne l’a pas. Les 500 $ de crédits UpCloud te donnent une fenêtre confortable pour tester sans engagement financier. Utilise-les pour monter un environnement de staging, mesurer tes coûts réels (compute + stockage sur ton profil d’usage spécifique), et valider que tu peux gérer le cycle opérationnel avant de migrer quelque chose de critique. Firebase reste une réponse valide pour les équipes dans l’écosystème Google qui n’ont pas de contraintes de conformité régionale et qui valorisent la simplicité opérationnelle. Supabase Cloud reste la meilleure option pour la majorité des équipes qui veulent l’open-source sans la complexité Kubernetes. Supabase sur UpCloud, c’est pour les équipes qui ont coché les bonnes cases : contrainte régionale réelle, volume d’egress significatif, expertise DevOps disponible, et horizon long terme sur l’architecture. Si tu te reconnais dans cette description, l’architecture est solide et les outils sont matures. Commence par les crédits UpCloud. Teste ton cas d’usage réel. Mesure tes coûts. Décide à partir de tes chiffres, pas des leurs. C’est tout.
Si ce type d’analyse infrastructure t’intéresse, inscris-toi au Tour de Table. Chaque semaine, les outils qui changent l’équation opérationnelle, sans langue de bois sur les coûts et les limites.
Check tes courriels.
Lien à cliquer pour confirmer ton abonnement.
Texte par David Cyr
