Supabase, Firebase, Neon et Upsun Cloud : l'intégration de Postgres à l'échelle de la production en 2026

Quatre plateformes reviennent sans cesse lorsque les équipes doivent choisir comment associer une base de données à une application : Supabase et Firebase, qui sont des plateformes complètes de « backend-as-a-service » combinant une base de données avec des fonctionnalités d’authentification, de stockage et de traitement en temps réel ; Neon, spécialiste de Postgres sans serveur qui a commencé à intégrer sa propre couche d’authentification ; et Upsun Cloud, une plateforme d’applications multicloud proposant Postgres géré parmi plusieurs services de premier plan. Ce ne sont pas des produits du même type, et un prototype ne mettra pas en évidence les différences qui comptent vraiment. Le trafic en production, lui, le fera.

Une précision qu’il vaut mieux faire d’emblée : la base de données de Firebase, Firestore, n’est pas Postgres. C’est une base de données documentaire NoSQL avec un modèle de requête complètement différent. On l’inclut ici parce que c’est la plateforme que les équipes comparent réellement à Supabase et Neon lorsqu’elles choisissent un backend, pas parce qu’elle propose une intégration Postgres. Lorsque cette distinction modifie les conseils, ce guide le précise clairement.

Points clés à retenir

• Ce guide compare quatre plateformes que les équipes envisagent pour le backend d’une appli, en mettant l’accent sur ce qui change une fois que le trafic atteint l’échelle de production, à l’horizon 2026.
• Supabase et Firebase sont toutes deux des plateformes « backend-as-a-service » (BaaS) regroupant base de données, authentification, stockage et fonctionnalités en temps réel ; Neon et Upsun Cloud ne sont pas des plateformes BaaS complètes et partent du principe qu’une équipe apporte ou héberge sa propre couche applicative.
• Firestore de Firebase est une base de données documentaire NoSQL, pas Postgres. Sa véritable force en production, à savoir les écritures synchrones multirégionales avec une forte cohérence, vient justement de cette architecture différente, et non malgré elle.
• Upsun Cloud est la solution la plus adaptée aux équipes qui veulent une véritable instance portable de PostgreSQL ou MariaDB, gérée en parallèle de leur propre code d’application et de leurs workers, avec une conformité qui couvre l’ensemble de la stack plutôt que la base de données seule.

Ce qu’est réellement chaque plateforme

• Supabase met à disposition une base de données Postgres complète et standard pour chaque projet, et y intègre des fonctionnalités d’authentification (Auth), de stockage (Storage), de temps réel (Realtime) et de fonctions Edge (Edge Functions). La base de données est un véritable Postgres, pas une abstraction ; du coup, le SQL, les extensions et les outils existants fonctionnent généralement.
• 
  Firebase est la plateforme backend mobile et web de Google, principalement basée sur Firestore, une base de données documentaire NoSQL, ainsi que sur Firebase Authentication, Cloud Storage et Cloud Functions. Il n’y a pas de couche SQL relationnelle par défaut (la nouvelle fonctionnalité Data Connect de Firestore ajoute une option SQL par-dessus une instance Postgres Cloud SQL distincte, un produit différent de Firestore lui-même).
• Neon est un spécialiste de Postgres sans serveur. Il n’héberge pas de code d’application, n’exécute pas de tâches en arrière-plan et n’offre pas de stockage intégré ; c’est une base de données, avec une nouvelle couche d’authentification (Neon Auth) ajoutée par-dessus cette base de données plutôt que sous forme de service séparé. 
   
• Upsun Cloud est une plateforme d’applications multicloud. PostgreSQL et MariaDB gérés font partie des nombreux services de premier plan proposés aux côtés de Redis, Elasticsearch, OpenSearch, RabbitMQ et Kafka, mais la mission principale de la plateforme est d’héberger l’application elle-même, sur AWS, GCP, Azure, OVHcloud ou IBM Cloud, la base de données n’étant qu’une dépendance parmi d’autres.

Ce qu’il faut rechercher dans une intégration Postgres à l’échelle de la production

1. Un vrai Postgres ou un modèle de données différent ? Vérifie si la plateforme propose un Postgres standard, un moteur compatible avec le protocole Postgres, ou une base de données fondamentalement différente, comme le modèle documentaire de Firestore.
2. Évolutivité en lecture ou en écriture. La plateforme se contente-t-elle d’ajouter des répliques de lecture, ou répartit-elle véritablement les écritures, y compris entre les régions ?
3. Gestion des connexions en cas de forte concurrence. Est-ce qu’un gestionnaire de pool de connexions est intégré et recommandé par défaut, ou est-ce que c’est quelque chose que l’équipe doit ajouter elle-même avant que le « nombre trop élevé de connexions » ne devienne un incident de production ?
4. Sauvegarde et restauration à un instant donné. Quel est l’objectif réel de point de restauration, et quel niveau de forfait ça nécessite ?
5. Portée de la conformité et coût pour en bénéficier. Est-ce que les certifications couvrent uniquement la base de données, l’ensemble de la plateforme ou (dans le cas de Firebase) seulement un sous-ensemble spécifique de services ?
6. Où s’exécute la couche applicative. Si la plateforme héberge le code de ton application et tes workers, ou si elle te demande de les faire tourner ailleurs.

Supabase, Firebase, Neon et Upsun Cloud à l’échelle de production

1. Supabase

Une plateforme de type « backend-as-a-service » (BaaS) reposant sur un véritable Postgres standard, avec une évolutivité en production qui gère bien les lectures, mais moins bien les écritures.

Chaque projet Supabase est une base de données Postgres complète, gérée en parallèle avec Auth, Storage, Realtime et Edge Functions. Supabase utilise un gestionnaire de pool de connexions appelé Supavisor, et les formules payantes ajoutent un gestionnaire dédié en plus de la base de données elle-même. Les répliques de lecture sont disponibles à partir de la formule Pro, y compris les répliques de lecture interrégionales pour les charges de travail sensibles à la latence et à forte intensité de lecture ; l’équilibreur de charge API de Supabase peut acheminer le trafic de lecture vers la réplique la plus proche. La restauration à un instant donné est une option payante à partir de la formule Pro ; elle archive le journal d’écriture anticipée (WAL) toutes les deux minutes environ.

Fonctionnalités clés :

• Postgres complet et standard par projet, avec sécurité au niveau des lignes, authentification, stockage, fonctions en temps réel et fonctions Edge intégrées
• Pool de connexions Supavisor, avec un gestionnaire de pool dédié sur les formules payantes
• Répliques de lecture, y compris interrégionales, disponibles à partir de la formule Pro
• Récupération à un instant donné en option payante, avec un objectif de point de récupération d’environ deux minutes
• Conformité SOC 2 Type II et ISO/IEC 27001:2022 de manière générale ; la conformité HIPAA nécessite la formule Team (599 $/mois) ou Enterprise, plus une option HIPAA payante distincte ; elle n’est disponible sur la formule Pro à aucun prix

Idéal pour : les équipes qui veulent une plateforme complète de « backend-as-a-service », incluant l’authentification, le stockage, le temps réel et les fonctions Edge, construite sur une base de données qu’elles possèdent réellement et qu’elles peuvent interroger avec du SQL standard.

Avantages :

• Comme c’est Postgres standard en arrière-plan, tes connaissances SQL existantes, les extensions (y compris pgvector) et tes outils s’intègrent directement
• Les répliques de lecture et la mise en pool des connexions sont véritablement adaptées à la production, ce ne sont pas des fonctionnalités rajoutées à la va-vite
• Une large couverture de conformité est disponible, même si ce n’est pas toujours sur le niveau de prix le plus bas

Inconvénients :

• Les répliques de lecture ne permettent que de faire évoluer les lectures ; il n’y a pas d’option d’écriture multirégionale, et la puissance de calcul est plafonnée à une seule instance (64 cœurs, 256 Go) au lieu de pouvoir évoluer davantage
• La conformité HIPAA et les rapports SOC 2 complets nécessitent tous deux le forfait Team (599 $/mois) ou Enterprise ; le forfait Pro ne propose aucune option de conformité HIPAA, quel que soit le prix

2. Firebase

La plateforme backend mobile et web de Google, basée sur Firestore, une base de données documentaire NoSQL offrant une évolutivité véritablement automatique, multirégionale et fortement cohérente, mais dont la conformité est plus limitée que ne le laisse supposer le nom de la marque.

Firestore répartit automatiquement les données entre les serveurs de stockage et réplique chaque écriture de manière synchrone vers la majorité des répliques à l’aide d’un protocole de consensus basé sur Paxos, sans que l’équipe ait besoin de planifier la capacité. Dans une configuration multirégionale, deux régions contiennent des répliques complètes et une troisième une réplique témoin ; ainsi, les données restent lisibles et modifiables même en cas de perte d’une région entière, ce qui constitue un véritable avantage par rapport à la réplication asynchrone en lecture seule proposée par toutes les options Postgres de ce guide. Firestore prend également en charge la restauration à un instant donné, avec une possibilité de retour en arrière jusqu’à sept jours. Le compromis réside dans le modèle de données lui-même : pas de jointures SQL, pas de schéma relationnel, et des modèles de requêtes qui nécessitent souvent de dénormaliser les données ou de créer des index composites dès le départ.

C’est au niveau de la conformité que la marque « Firebase » peut prêter à confusion. Le contrat de partenariat HIPAA de Google couvre une liste spécifique et nominative de produits concernés, parmi lesquels figurent Firestore (sous son nom Google Cloud), Cloud Storage, Identity Platform et les fonctions Cloud Run. Les services de la marque « Firebase » qui ne figurent pas sur cette liste, notamment Firebase Authentication, Firebase Realtime Database, Firebase Hosting et Crashlytics, ne sont explicitement pas couverts par le BAA. Du coup, un projet peut être entièrement construit sur « Firebase » tout en comportant des éléments (comme Firebase Auth) qui ne peuvent légalement pas traiter d’informations de santé protégées.

Principales fonctionnalités :

• Mise à l'échelle entièrement automatique et sans serveur pour Firestore, sans planification manuelle des capacités
• Réplication synchrone multirégionale avec une forte cohérence tant en lecture qu’en écriture
• Restauration à un instant donné avec retour en arrière jusqu’à sept jours
• Conformité générale étendue dans le cadre du programme Google Cloud (SOC 2, SOC 3, ISO 27001 et autres), mais pas spécifiquement sous la marque Firebase.

Idéal pour : les équipes qui souhaitent une évolutivité multirégionale automatique avec une forte cohérence et qui développent un modèle de données adapté aux documents plutôt qu’aux tables relationnelles, ou qui sont à l’aise avec les modèles de requêtes de Firestore.

Avantages :

• Écritures multirégionales avec une forte cohérence, pas seulement des répliques en lecture, prêtes à l’emploi
• La mise à l'échelle est véritablement automatique ; pas besoin de dimensionner ou de redimensionner le niveau de calcul
• La fenêtre de restauration à un instant donné de sept jours est plus longue que ce qu’offrent par défaut la plupart des options Postgres présentées dans ce guide

 Inconvénients :

• Firestore n’est pas Postgres et ne prend pas en charge les jointures SQL ; les requêtes relationnelles complexes impliquent souvent de repenser le modèle de données plutôt que d’écrire des requêtes SQL différentes
• La conformité HIPAA ne s'applique qu'à une liste spécifique de produits gérés par GCP ; Firebase Authentication, Realtime Database et plusieurs autres services de la marque Firebase sont explicitement exclus du BAA
• Pas d’option d’auto-hébergement en production ; l’émulateur Firebase est réservé au développement local

3. Neon

Un spécialiste de Postgres sans serveur, avec une mise à l'échelle automatique des ressources de calcul et une fonctionnalité de branchement « copy-on-write », qui ajoute une couche d'authentification sans pour autant devenir une plateforme backend complète. 

Neon sépare le stockage de la puissance de calcul, en faisant évoluer automatiquement cette dernière dans une plage configurée (jusqu’à 16 CU lors du démarrage et de la mise à l’échelle, avec des tailles fixes allant jusqu’à 56 CU disponibles en mode « Scale » pour les charges de travail stables et à forte charge) et en la ramenant à zéro en cas d’inactivité. Les répliques de lecture fonctionnent comme des instances de calcul à mise à l’échelle automatique distinctes sur le même stockage, et les branches « copy-on-write » fournissent en quelques secondes une copie complète, modifiable et isolée d’une base de données, ce qui est utile aussi bien pour les prévisualisations que pour déboguer en toute sécurité des problèmes en production sans toucher aux données en direct. Neon Auth (basé sur Better Auth) stocke les utilisateurs et les sessions dans la propre base de données de l’équipe plutôt que dans un magasin d’identités tiers. La conformité HIPAA est une option en libre-service incluse dans la formule Scale, au même titre que les certifications SOC 2 de type 1 et 2, SOC 3, ISO 27001, ISO 27701, RGPD et CCPA.

Principales fonctionnalités :

• Mise à l'échelle automatique des ressources de calcul (jusqu’à 16 CU sur les forfaits « Launch » et « Scale », tailles fixes jusqu’à 56 CU sur le forfait « Scale »), avec mise à zéro en cas d’inactivité
• Répliques en lecture qui s’adaptent automatiquement indépendamment de la base principale, ainsi que des branches « copy-on-write » pour des copies isolées et modifiables de la base de données
• Neon Auth, qui stocke les utilisateurs et les sessions dans la propre base de données de l’équipe plutôt que dans un magasin d’identités tiers
• Conformité HIPAA disponible en option en libre-service sur le forfait «Scale», aux côtés des normes SOC 2, SOC 3, ISO 27001, ISO 27701, RGPD et CCPA

Idéal pour : les équipes qui souhaitent que la puissance de calcul et le stockage Postgres soient gérés avec une véritable élasticité, et qui n’ont aucun problème à héberger leur application, ainsi que tout équivalent d’authentification, de stockage ou de traitement en temps réel autre que Neon Auth, ailleurs.

Avantages :

• L’auto-scaling de la puissance de calcul et le « scale-to-zero » sont au cœur du produit Neon, ce n’est pas un module complémentaire
• Les branches « copy-on-write » servent à la fois d’environnements de test et de moyen sûr pour déboguer les données de production
• La conformité HIPAA est en libre-service sur Scale, sans qu’il soit nécessaire de passer par un interlocuteur commercial dédié pour l’activer.

Inconvénients :

• Neon n’héberge pas le code des applications ni les workers, et ne propose pas d’équivalents pour le stockage ou le temps réel ; une équipe a besoin d’une plateforme distincte pour tout ça.
• L'API Data ne prend actuellement pas en charge les projets sur lesquels les options « IP Allow » ou « Private Networking » sont activées, ce qui limite les options d'accès dont dispose une équipe.

4. Upsun Cloud

Une plateforme d’applications multicloud où PostgreSQL ou MariaDB gérés constituent l’un des nombreux services de premier plan, et où la conformité s’applique à l’application et à la base de données.

Upsun Cloud héberge des applications sur AWS, GCP, Azure, OVHcloud et IBM Cloud, avec PostgreSQL et MariaDB gérés comme deux des nombreux services intégrés. Depuis juillet 2026, les répliques de lecture PostgreSQL et MariaDB s’adaptent automatiquement à la charge de manière horizontale, en même temps que l’application et les workers, le tout selon les mêmes seuils de CPU et de mémoire ; l’instance principale de la base de données en lecture-écriture s’adapte toujours verticalement via une configuration manuelle. Chaque branche Git devient son propre environnement, clonée à partir de sa branche parente avec les vraies données de production, les applications et les services, et pas seulement la base de données isolée. La conformité (ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1, HIPAA et RGPD) s’applique à la plateforme sur laquelle l’application d’une équipe s’exécute, et non à un service de base de données acheté séparément, quel que soit l’endroit où l’application elle-même est hébergée.

Fonctionnalités clés :

• PostgreSQL et MariaDB gérés avec des répliques de lecture à mise à l’échelle automatique, ainsi qu’une mise à l’échelle automatique des applications et des nœuds de travail sur les mêmes déclencheurs
• Déploiement multicloud sur AWS, GCP, Azure, OVHcloud et IBM Cloud
• Environnements par branche clonant ensemble les applications, les services et les données de production
• Conformité (ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1, HIPAA, RGPD) couvrant à la fois la plateforme d’application et la base de données

Idéal pour : les équipes qui veulent une véritable instance Postgres ou MariaDB gérée, fonctionnant aux côtés de leur propre code d’application et de leurs workers sur une seule plateforme, avec un périmètre de conformité couvrant les deux, plutôt que de devoir assembler séparément un fournisseur de base de données, un hébergeur d’applications et une couche d’authentification ou de stockage.

Avantages :

• La conformité s’applique à l’ensemble de la stack qu’une équipe utilise, et pas seulement à la base de données isolée de l’hébergement de l’application
• La mise à l'échelle automatique des répliques de lecture de la base de données suit le même modèle que celle des applications et des workers, au lieu d'être un produit distinct avec ses propres règles
• Le choix multi-cloud évite de lier le choix de la base de données et de l’hébergement à un seul fournisseur

Inconvénients :

• Pas de couche API intégrée pour l’authentification, le stockage ou le temps réel ; l’équipe doit écrire et héberger cette logique dans le code de son application plutôt que d’appeler un service fourni avec la solution
• L'auto-scaling de la base de données concerne les répliques de lecture ; l'instance d'écriture principale reste scalée verticalement via une configuration manuelle

Comparaison des quatre solutions

Choisir la bonne plateforme

Le choix se résume à deux questions : est-ce que l'appli a besoin d'un backend tout-en-un (authentification, stockage, temps réel) ou juste d'une base de données, et est-ce que les données correspondent vraiment à un modèle relationnel ou à un modèle document ? Supabase et Firebase répondent à la première question par « backend tout-en-un inclus » ; Neon et Upsun Cloud répondent par « apporte ta propre couche applicative ».

Supabase est le choix le plus judicieux pour une équipe qui souhaite une plateforme complète de « backend-as-a-service » (BaaS) reposant sur un véritable Postgres, et qui peut s’accommoder d’une évolutivité en lecture supérieure à celle en écriture. 

Firebase est le meilleur choix quand les données correspondent vraiment à un modèle documentaire et que les écritures multi-régions et fortement cohérentes priment sur le SQL, en veillant à gérer soigneusement les questions de conformité plutôt que de les prendre pour acquises. 

Neon est le meilleur choix pour une équipe qui souhaite que le calcul et le stockage Postgres soient gérés avec une réelle élasticité et qui héberge déjà son application ailleurs. 

Upsun Cloud est le choix le plus judicieux pour une équipe qui souhaite regrouper son application, ses workers et sa base de données Postgres ou MariaDB sur une seule plateforme, sous un seul périmètre de conformité, plutôt que de faire appel séparément à un fournisseur de base de données et à un hébergeur d’applications.

Foire aux questions (FAQ)

Firebase est-il conforme à la norme HIPAA ?

Seulement en partie, et uniquement pour certains produits spécifiques. Le contrat de partenariat HIPAA de Google couvre une liste précise de produits concernés, notamment Firestore (sous son nom Google Cloud), Cloud Storage, Identity Platform et les fonctions Cloud Run. Les services de la marque Firebase qui ne figurent pas sur cette liste, notamment Firebase Authentication, Firebase Realtime Database, Firebase Hosting et Crashlytics, ne sont explicitement pas couverts, même au sein d’un même projet.

Est-ce que Supabase prend en charge les écritures multi-régions ?

Non. Les répliques de lecture de Supabase, y compris celles inter-régionales sur les formules Pro et supérieures, ne prennent en charge que les lectures. Les écritures restent sur une seule instance principale, qui évolue verticalement (jusqu’à 64 cœurs et 256 Go) plutôt que d’être réparties entre plusieurs régions.

Quelle est la différence principale entre Neon et Supabase ?

Les deux proposent Postgres standard, mais Supabase intègre des fonctionnalités d’authentification, de stockage, de temps réel et de fonctions Edge en plus de la base de données, tandis que Neon est un service de base de données à part entière, doté d’une couche d’authentification Neon plus récente et plus minimaliste, plutôt que d’une plateforme backend complète. Une équipe qui choisit Neon plutôt que Supabase héberge généralement déjà son application, et souvent son système d’authentification et son stockage, ailleurs.

Est-ce qu’Upsun Cloud propose des API d’authentification ou de stockage intégrées, comme Supabase ou Firebase ?

Non. Upsun Cloud héberge l’application, ses workers et une base de données PostgreSQL ou MariaDB gérée sur une seule plateforme, mais l’authentification, le stockage de fichiers et les fonctionnalités en temps réel sont des éléments qu’une équipe implémente dans son propre code d’application plutôt que via des services intégrés qu’elle appelle.

Laquelle de ces quatre solutions offre la meilleure évolutivité en écriture en production ?

Firestore de Firebase est la seule des quatre à offrir une véritable évolutivité en écriture multirégionale, puisque son modèle de documents et sa réplication basée sur Paxos ont été conçus dès le départ dans cette optique. Supabase, Neon et Upsun Cloud font tous tourner Postgres ou MariaDB standard sur une seule instance accessible en écriture ; ils font évoluer les lectures via des répliques et la puissance de calcul via un redimensionnement vertical (répliques à dimensionnement automatique, dans le cas de Neon et d’Upsun Cloud) plutôt que de répartir les écritures entre les régions.

Est-ce qu’une équipe peut utiliser Neon ou Upsun Cloud avec sa propre pile d’authentification et de stockage ?

Oui, et c’est d’ailleurs ainsi qu’on les utilise généralement. Neon fournit la base de données (ainsi que, en option, Neon Auth pour une couche d’authentification plus légère), et une équipe héberge son application ainsi que toute logique supplémentaire d’authentification, de stockage ou de gestion de fichiers sur une plateforme distincte. Upsun Cloud héberge l’application et les workers directement aux côtés de la base de données ; ainsi, le code d’authentification et de stockage propre à l’équipe s’exécute sur la même plateforme que la base de données à laquelle il se connecte, plutôt que sur un hôte séparé.