Supabase ou Firebase : SQL et coûts à l’usage

Pour un SaaS où comptes, abonnements, factures et droits sont étroitement liés, Supabase est généralement le choix le plus direct. Pour une application dont les clients suivent surtout des documents mis à jour en temps réel, Cloud Firestore peut mieux correspondre aux accès prévus. Dans les deux cas, les opérations et les données sortantes peuvent peser davantage que le tarif d’entrée.

Il faut aussi préciser quel service Firebase entre dans la comparaison : Cloud Firestore est une base documentaire, tandis que SQL Connect donne accès à PostgreSQL. Le choix porte donc sur la structure des données, la charge que l’application créera et le travail nécessaire si elle change de backend. Un prototype, un SaaS relationnel et une application très interactive exposent des risques différents.

Des relations ou des documents suivis par les clients ?

Une base relationnelle exprime directement les liens entre un compte, ses abonnements, ses factures et les droits de ses membres. La FAQ de facturation de Supabase précise que chaque projet possède sa propre machine virtuelle et sa base PostgreSQL, et que le calcul d’un projet payant dépend du temps d’utilisation de son instance. La simplicité du modèle de données ne dispense donc pas de dimensionner cette ressource.

Avec une base documentaire, la structure doit correspondre aux documents que chaque écran lit et suit réellement. Si une vue rassemble des informations dispersées dans plusieurs collections, elle peut multiplier les lectures ou conduire à conserver des copies de certaines données. La copie accélère parfois l’affichage, mais chaque modification doit alors être répercutée aux bons endroits. Ce compromis paraît plus naturel pour des contenus largement indépendants que pour des permissions ou des écritures comptables qui doivent rester cohérentes entre plusieurs entités.

Le temps réel ne tranche pas seul : les deux architectures peuvent transmettre des changements aux clients. La question décisive est de savoir ce qui change, combien de destinataires reçoivent la mise à jour et quelles autres données l’écran doit charger pour rester cohérent.

Prototype : le premier seuil atteint n’est pas forcément celui de la base

Les tarifs de Supabase indiquent que l’offre gratuite comprend 500 Mo de base, 5 Go de sortie réseau, 50 000 utilisateurs actifs mensuels pour l’authentification, deux millions de messages Realtime par mois et 200 connexions simultanées au pic ; Pro commence à 25 dollars par mois. Un prototype qui distribue des fichiers volumineux peut épuiser sa sortie réseau alors que sa base reste petite. À l’inverse, des clients connectés en permanence peuvent rencontrer une limite de connexions avant de manquer d’espace.

La grille Firebase indique que Blaze conserve des quotas gratuits de Spark, dont, pour Cloud Firestore Standard, 50 000 lectures et 20 000 écritures de documents par jour ainsi que 10 Gio de sortie réseau par mois ; Firebase Hosting dispose de son propre quota de transfert de 360 Mo par jour, puis facture le dépassement à l’usage. Un passage à Blaze permet ainsi de continuer au-delà de certains seuils, avec une facture potentielle à la clé. Il faut additionner les services réellement utilisés plutôt que traiter l’ensemble du projet comme une seule réserve gratuite.

Dans un exemple purement hypothétique, cent testeurs ouvrent chacun vingt documents cinq fois dans une journée. Cela représente jusqu’à 10 000 lectures avant de tenir compte du cache, des écouteurs ou d’autres requêtes. Pour le même prototype, la taille des réponses et celle des fichiers téléchargés doivent être estimées séparément : peu de lectures peuvent tout de même produire beaucoup de trafic.

SaaS relationnel : comparer deux déploiements complets

Quand un produit croise souvent organisations, membres, droits et factures, un schéma relationnel évite de reconstruire ces liens dans les lectures clientes et la logique applicative. Pour chiffrer Supabase, le prix du forfait doit être rapproché du calcul nécessaire à chaque projet, de l’espace de base, de l’authentification et des données sortantes. Des environnements distincts pour le développement et la production peuvent aussi changer le nombre d’instances à financer.

La tarification de Firebase SQL Connect distingue le service de requêtes de l’instance Cloud SQL pour PostgreSQL qui héberge les données : l’essai de l’instance sur Spark dure 90 jours, tandis que Blaze inclut un seuil mensuel de 250 000 opérations clientes et de 10 Gio de sortie réseau pour le service. L’opération cliente y est l’unité de facturation du service de requêtes, sans tarif par ligne lue ; l’instance PostgreSQL constitue un autre poste après l’essai applicable. Comparer ce déploiement à Supabase exige donc d’inclure le calcul et les services associés des deux côtés.

Une estimation utile part des gestes du produit : combien de membres consultent les factures, à quelle fréquence, quelle taille ont les pièces jointes et quelles tâches tournent en arrière-plan ? Ces hypothèses déterminent les requêtes, le trafic et la capacité requise. Le prix mensuel affiché pour un forfait ou une petite instance, pris isolément, ne décrit pas ce coût complet.

Temps réel : une mise à jour peut devenir plusieurs lectures

La facturation de Cloud Firestore compte une lecture lorsqu’un document entre dans le résultat d’un écouteur ou y est mis à jour ; selon la persistance hors ligne et la durée de déconnexion, une reconnexion peut aussi relancer la facturation des lectures. Certaines requêtes entraînent en outre des lectures d’entrées d’index. Le nombre d’écritures dans la base ne suffit donc pas à prévoir le coût d’une application dont de nombreux clients suivent les mêmes données.

Supposons, uniquement pour dimensionner la charge, mille clients qui ouvrent chacun une liste de vingt documents. L’ouverture représente 20 000 lectures si chaque document est effectivement lu ; si chaque élément suivi change quatre fois et que tous les clients reçoivent chaque changement, les mises à jour peuvent ajouter 80 000 lectures. Ce calcul conditionnel n’est ni un benchmark ni une facture prévisible : le cache, les filtres et les déconnexions modifieraient le résultat.

Dans l’autre architecture, il faut traduire cette même activité en messages transmis, en connexions au pic et en octets sortants, puis vérifier la capacité PostgreSQL nécessaire pour produire les changements. Envoyer moins d’événements, limiter les destinataires ou réduire la taille des messages peut modifier la charge. Comparer seulement un quota de lectures à un quota de messages donnerait une réponse trompeuse, car ces unités ne représentent pas la même opération.

Portabilité : compter ce qu’il faudra reconstruire

Le format relationnel offre une voie familière pour déplacer schéma et données PostgreSQL. Un déménagement d’application comprend toutefois davantage que la base : règles d’accès, comptes utilisateurs, fichiers, fonctions, abonnements aux changements et code client doivent être examinés séparément. Le travail dépend des services réellement adoptés, même lorsque le moteur de base reste le même.

Quitter une structure documentaire pour un schéma relationnel ajoute la transformation des documents et des index, puis la réécriture des lectures qui alimentent les écrans. Pour un SaaS riche en relations, ce travail potentiel renforce l’intérêt d’un modèle SQL dès le départ ; pour des clients qui suivent surtout des documents autonomes, la structure documentaire peut rester plus simple. Le choix le plus défendable est celui dont on peut décrire à la fois les unités consommées sous forte charge et les dépendances à remplacer en cas de migration.