Début 2025, quand on a démarré NHS Finances, on a hésité entre Firebase et Supabase. Les deux outils proposent à peu près la même promesse : "backend as a service" avec auth, base de données, fonctions serverless, real-time, et stockage.
On a choisi Supabase. Voici pourquoi, et surtout ce qui s'est passé après.
Le critère qui a fait pencher la balance
Postgres. Pas Supabase. Postgres.
Firestore est une base NoSQL orientée document. C'est rapide à mettre en place, ça scale bien, mais dès qu'on commence à faire de l'analytique financière sérieuse, on tombe sur ses limites :
- Les jointures sont inexistantes (ou à émuler côté client)
- Les agrégations complexes (GROUP BY, window functions, CTE) ne sont pas natives
- Les requêtes coûtent par document lu — sur des dashboards qui scannent des milliers de lignes, ça chiffre vite
Postgres, lui, c'est 35 ans de maturité. Toutes les fonctions analytiques qu'on peut imaginer, plus les extensions (timescaledb, postgis, pgvector si on veut faire de l'IA).
Pour une app financière qui passe sa vie à faire des agrégations multi-dimensionnelles, le SQL n'est pas un confort, c'est une nécessité.
Ce que Supabase apporte au-dessus
Supabase, c'est Postgres + une couche de services qui font gagner un temps précieux :
Row Level Security au lieu de règles de sécurité externes
Avec Firestore, les règles de sécurité sont dans un fichier séparé, avec une syntaxe spécifique. Avec Supabase, c'est du SQL standard exécuté dans la base elle-même. Un dev qui connaît Postgres écrit ses policies en 5 minutes.
Auth intégrée et personnalisable
L'auth Supabase est un wrapper autour de GoTrue (Netlify). Email/password, OAuth (Google, GitHub, etc.), magic links, MFA — tout est là. Et surtout, l'utilisateur authentifié est directement disponible dans toutes vos requêtes SQL via auth.uid().
Edge Functions Deno
Pour la logique serveur (webhooks, intégrations API, traitements lourds), Supabase propose des Edge Functions en Deno. C'est plus moderne et plus rapide à démarrer que les Cloud Functions Firebase, et ça tourne dans la même région que la base.
Realtime via Postgres logical replication
Le realtime de Supabase écoute le WAL Postgres. Tout changement dans la base peut être pushé en temps réel à un client connecté. On l'utilise pour la mise à jour live du dashboard quand une sync Cegid se termine.
Ce qui n'a pas été simple
Pour être honnête, Supabase a aussi ses pièges :
- Les migrations : il faut une vraie discipline (on utilise les scripts SQL versionnés, on est à 9 scripts pour NHS Finances)
- Les performances RLS : sur des policies complexes, ça peut ralentir les requêtes. Bien indexer.
- Le pricing : moins prévisible que Firebase sur les gros volumes, à surveiller.
Si c'était à refaire
On referait exactement le même choix. Postgres + Supabase, c'est la stack qu'on recommande à 9 clients sur 10 pour les applications métier. Pour des cas très spécifiques (très haute écriture, faible analytique), Firebase peut rester pertinent. Mais le ratio puissance/simplicité de Supabase est imbattable en 2026.
Vous hésitez sur votre stack ? On en discute en 30 minutes, sans vous vendre quoi que ce soit.