Comparatif · SaaS & dev
Supabase, Firebase, Neon : lecture des docs
Docs Supabase, Firebase et Neon lues le 2026-10-18. Postgres, documents, auth et fichiers. Aucun test n’a été exécuté, et aucun prix n’est recopié.
Supabase, Firebase et Neon ne tiennent pas le même rôle dans les pages ouvertes le 2026-10-18. Supabase se décrit comme une suite ouverte autour de Postgres. Firebase documente surtout des bases documents, une auth et des fichiers, avec des règles côté client. Neon se présente désormais comme un backend dont le cœur reste Postgres, avec auth, API HTTP, fichiers et fonctions cités sur la page d’introduction. Aucun test n’a été exécuté pour écrire cette page, et aucun prix n’est recopié.
Cette lecture ne classe pas. Elle sépare ce que les docs disent de ce qu’un essai aurait dû montrer.
Supabase
Pages lues : Architecture, Database, connexion Postgres, Edge Functions, Realtime, Storage.
La page d’architecture dit que Supabase n’est pas une copie de Firebase. Le choix assumé est Postgres, pas un store NoSQL. Le projet expose plusieurs services devant une seule instance : GoTrue pour l’auth JWT, PostgREST pour une API REST tirée du schéma, Realtime, Storage, des fonctions, pg_graphql. La page dit que Postgres n’est pas masqué : on y accède avec les privilèges complets. Les sources liées sont ouvertes. La référence d’auth pointe aussi vers une doc d’auto-hébergement. Je n’ai pas rejoué une installation.
Chaque projet a donc une base Postgres, pas une abstraction. Auth, Storage, Realtime et Edge Functions s’appuient dessus. Les sauvegardes quotidiennes couvrent la base. La restauration à un instant donné est indiquée sur les plans payants. Le montant n’est pas recopié. Les objets passés par l’API Storage ne sont pas dans ces sauvegardes de base. La page le dit explicitement.
Avant d’exposer une table au client, la doc demande le Row Level Security. La page de connexion distingue les cas : API de données pour un frontend, pooler en mode transaction pour une fonction courte, connexion directe pour pg_dump, une migration ou la réplication. Ce n’est pas un détail d’interface. Une fonction qui ouvre beaucoup de connexions TCP courtes n’utilise pas la même chaîne qu’un backend qui reste allumé.
Les Edge Functions sont des fonctions TypeScript, runtime compatible Deno, distribuées. Realtime documente trois usages : Broadcast pour des messages entre clients, Presence pour l’état des connectés, Postgres Changes pour écouter la base. La page Storage décrit des buckets de fichiers, le contrôle d’accès, et des envois compatibles S3. Je n’ai pas mesuré un upload.
Firebase
Pages lues : Cloud Firestore, Realtime Database, Authentication, Cloud Storage, Cloud Functions.
Firestore est une base documents, organisée en collections. Les SDK client, avec les Security Rules et Firebase Authentication, sont documentés pour qu’une app mobile ou web parle à la base sans serveur à vous. La page cite des listeners temps réel, un cache hors ligne sur mobile et web, et des transactions ACID. Elle distingue une édition Standard et une édition Enterprise. L’édition Enterprise ajoute une API compatible MongoDB. Ce n’est pas devenu du Postgres.
Realtime Database est un second produit. Les données y sont du JSON, synchronisé vers les clients connectés, avec persistance disque hors ligne. La page elle-même renvoie vers Firestore si vous voulez un modèle plus riche et des requêtes plus expressives. Les deux ne sont donc pas interchangeables dans la doc.
L’auth documente email et mot de passe, numéro de téléphone, et des fournisseurs fédérés, dont Google, Facebook, Twitter et GitHub. FirebaseUI est présenté comme un flux d’interface prêt. Une montée vers Authentication with Identity Platform débloque, selon la page, l’authentification à plusieurs facteurs, les blocking functions, SAML, l’OpenID Connect générique et le multi-tenant. Aucun tarif de cette montée n’est recopié.
Cloud Storage for Firebase envoie les fichiers dans un bucket Google Cloud Storage. Les règles déclaratives filtrent selon le nom, la taille, le type. Cloud Functions for Firebase exécute du JavaScript, du TypeScript ou du Python, sur événement Firebase ou Google Cloud, sur requête HTTPS, ou via Cloud Scheduler. Le code tourne dans un environnement géré. La page ne décrit pas un Postgres au centre du projet.
Neon
Pages lues : Introduction, Lakebase Postgres, Branching, Auth, Data API, Object Storage.
L’introduction, relue le 2026-10-18, ne limite plus Neon à une base. Elle liste Lakebase Postgres, Auth, une Data API, Object Storage, Functions et un AI Gateway. Je n’ai pas ouvert la page Functions au-delà de cette description : des fonctions Node.js, longues, déployées à côté de la base. Les limites de durée de cette page-là ne sont pas reprises ici.
Lakebase Postgres est documenté comme du Postgres géré, compatible avec les drivers habituels. La page cite l’autoscaling, la suspension quand la base est inactive, les branches, la restauration dans la fenêtre d’historique, et des replicas de lecture. La formule « you only pay for what you use » figure sur cette page. Aucun barème n’est recopié.
Une branche est un clone copy-on-write, isolé de son parent. On peut la créer depuis l’état courant ou un état passé, ou en schema-only si les données sont sensibles. La page dit que la création ne charge pas le parent. Le guide de workflow écrit qu’une branche se crée en environ une seconde, quelle que soit la taille. C’est une phrase de la doc, pas un chronomètre lancé ici. Chaque branche a sa propre chaîne de connexion.
Managed Better Auth stocke utilisateurs, sessions et configuration dans le schéma neon_auth. Une branche de la base emporte cet état d’auth. La doc dit que c’est une API REST gérée, et que les données restent interrogeables en SQL, avec RLS.
La Data API est une interface HTTP, compatible PostgREST, pour un navigateur ou un runtime edge où un driver TCP se comporte mal. Elle valide des JWT et applique le RLS. La page dit qu’on peut utiliser Managed Better Auth, ou un autre fournisseur, et elle cite Auth0, Clerk ou Firebase. L’introduction appelle cette API « drop-in compatible with Supabase ». Je n’ai pas branché un client Supabase dessus. La phrase reste une affirmation de Neon, pas un essai.
Object Storage est compatible S3 et se branche avec la base : une branche de prévisualisation a sa vue des fichiers. La page limite, à la date de lecture, les régions à AWS US East (Ohio), AWS US East (Virginie du Nord), Europe (Francfort) et Asie-Pacifique (Singapour). Elle renvoie vers une page de plans pour les tarifs de stockage et de sortie. Ces tarifs ne sont pas recopiés.
Côté à côte, sans rang
| Point relu le 2026-10-18 | Supabase | Firebase | Neon |
|---|---|---|---|
| Données | Postgres, accès direct documenté | Firestore en documents ; Realtime Database en JSON | Postgres, drivers habituels |
| Auth | GoTrue, JWT, lié au RLS | Firebase Authentication, règles des produits Firebase | Managed Better Auth dans neon_auth, branché avec la base |
| Fichiers | Storage, envois S3 documentés sur le guide | Bucket Google Cloud Storage, SDK client | Object Storage S3, régions listées ci-dessus |
| Temps réel | Broadcast, Presence, Postgres Changes | Listeners Firestore et synchro Realtime Database, cache hors ligne cité | Non repris sur les pages ouvertes |
| Fonctions | Edge Functions TypeScript, runtime Deno | Cloud Functions, JS, TS ou Python | Citées en Node.js sur l’introduction ; limites non recopiées |
| Copie d’environnement | Non décrite comme un clone copy-on-write sur les pages ouvertes | Non décrit | Branches, y compris schema-only |
| Sortie des données | pg_dump cité pour l’import et la connexion directe | Modèle documents, pas un dump Postgres | Postgres standard, d’après la page Lakebase |
Une case « non repris » veut dire que les pages ouvertes ce jour-là ne le décrivaient pas. Elle ne prouve pas l’absence du produit.
Cas où l’autre option reste préférable
Firebase reste préférable si le client est une app mobile ou web qui doit lire et écrire hors ligne, avec le cache que les pages Firestore et Realtime Database décrivent, et si le modèle documents vous suffit. Il reste préférable aussi quand les déclencheurs dont vous avez besoin sont ceux que Cloud Functions documente, par exemple un événement Auth ou Storage. Passer à Postgres dans ce cas change le modèle de données.
Supabase reste préférable si vous voulez Postgres, une API REST tirée du schéma, le RLS lié à l’auth, et la pile ouverte que la page d’architecture décrit, y compris les pointeurs d’auto-hébergement. Il reste préférable à Neon si vous avez besoin, dès maintenant, de Broadcast et Presence tels que la page Realtime les nomme. Je n’ai pas trouvé l’équivalent sur les pages Neon ouvertes.
Neon reste préférable si le geste qui compte est une branche Postgres isolée, avec ou sans les lignes, pour un preview ou un job de CI. La Data API reste préférable à un driver TCP si le code tourne dans un navigateur ou un runtime edge, et si vous avez déjà une auth JWT ailleurs : la page cite Firebase parmi les fournisseurs possibles. Object Storage reste un mauvais défaut si votre région n’est pas dans la liste lue le 2026-10-18. Supabase Storage ou Cloud Storage for Firebase ne publient pas cette même liste sur les pages ouvertes.
Garder la base actuelle reste préférable si la migration n’a pas de dump ni de mapping documenté. pg_dump est cité chez Supabase pour du Postgres. Rien dans les pages Firebase lues ne transforme une collection Firestore en tables. Je n’ai pas fait cette conversion.
Ce qui n’a pas été fait
Aucun test n’a été exécuté. Aucun projet n’a été créé, aucune ligne insérée, aucun fichier envoyé. Aucun prix n’est recopié. Les pages de plans existent. Leurs montants restent à vérifier au moment d’une décision, ils ne sont pas dans ce texte.