Supabase vs Firebase vs Neon : la bonne DB pour votre SaaS en 2026

Réponse rapide : Supabase pour 90 % des SaaS web (Postgres + Auth + RLS + always-on, prix prévisible, EU dispo). Neon si workflow Vercel + preview environments par feature. Firebase uniquement pour apps mobiles native temps-réel. Postgres bat Firestore sur quasi toutes les métriques en 2026 — flexibilité, coût, portabilité.

1. Comparatif 12 critères

2. Tarifs 2026 et coût réel à 100 000 users

Le cas Firebase est trompeur. Sur le papier, le free tier semble généreux (1 GB Firestore, 50K reads/jour). En réalité, dès qu'un user ouvre une page qui liste 50 documents, vous comptez 50 reads. Pour 100K MAU avec 10 reads/MAU/jour = 1 M reads/jour = 30 M reads/mois → ~$120/mois Firestore, plus le coût des fonctions et du storage. Le doublement du trafic double exactement la facture, ce qui rend la planification délicate.

3. RLS : la feature qui change tout

Row Level Security est une feature Postgres native qui définit des règles d'accès au niveau de la ligne. Au lieu d'écrire WHERE user_id = current_user_id dans 50 endroits de votre code, vous écrivez UNE policy SQL et toutes les queries sont automatiquement filtrées.

Pattern type Supabase

-- Activer RLS sur la table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Policy : un user voit uniquement ses propres projets
CREATE POLICY "Users see own projects"
  ON projects FOR SELECT
  USING (auth.uid() = user_id);

-- Policy : un user crée des projets pour lui-même
CREATE POLICY "Users insert own projects"
  ON projects FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Policy : update/delete uniquement ses projets
CREATE POLICY "Users update own projects"
  ON projects FOR UPDATE
  USING (auth.uid() = user_id);

CREATE POLICY "Users delete own projects"
  ON projects FOR DELETE
  USING (auth.uid() = user_id);

Une fois ces policies en place, le client Supabase côté front ne peut JAMAIS voir les données d'un autre user. Même si votre code applicatif a un bug, même si quelqu'un appelle l'API REST avec sa propre clé : la DB filtrera. C'est la sécurité ultime.

Avantages vs vérification applicative

• Centralisation : invariants de sécurité dans la DB, pas répliqués dans 20 routes.
• Defense in depth : même un bug code n'expose pas les données.
• Auditabilité : audit de sécurité = lecture des policies SQL.
• Multi-tenant facile : ajouter org_id dans le RLS gère le multi-tenancy à zéro coût.

L'équivalent Firebase : Security Rules

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /projects/{projectId} {
      allow read: if request.auth != null && resource.data.userId == request.auth.uid;
      allow create: if request.auth != null && request.resource.data.userId == request.auth.uid;
      allow update, delete: if request.auth != null && resource.data.userId == request.auth.uid;
    }
  }
}

Ça marche, mais c'est un DSL Firebase spécifique, plus difficile à auditer, à tester, à reuser que du SQL standard. Et vous ne pouvez pas le porter ailleurs.

4. Migration Firebase → Supabase : les étapes

Si vous décidez de quitter Firebase pour Postgres (Supabase ou Neon), voici la procédure standard. Comptez 1 à 1,5 semaine selon le volume de données et la complexité du code.

Semaine 1 : Schéma + export

1. Lister toutes les collections Firestore (top-level + sub-collections).
2. Pour chaque collection, dessiner une table Postgres équivalente. Sub-collections → table liée par foreign key.
3. Exporter Firestore via gcloud firestore export ou Firebase Admin SDK + script Node.js.
4. Données denormalisées Firestore → normalisées Postgres (split en plusieurs tables).

Semaine 2 : Import + tests

1. Script de transformation : JSON Firestore → COPY Postgres.
2. Validation des contraintes (unique, foreign keys).
3. Tests sur un sous-ensemble : 1000 users, 10 000 documents.

Semaine 3 : Code refactoring

1. Remplacer les imports firebase/firestore par @supabase/supabase-js.
2. Convertir les listeners onSnapshot → Supabase Realtime channels ou polling SWR.
3. Convertir les queries Firestore → SQL via Supabase client ou Drizzle/Prisma.
4. Migrer les Cloud Functions → Supabase Edge Functions ou API routes Next.js.

Semaine 4 : Auth + Storage + Cutover

1. Migrer Firebase Auth → Supabase Auth (réutilisation des UIDs si possible).
2. Migrer Firebase Storage → Supabase Storage (copy SDK to SDK).
3. Double-run : 24-48h avec écritures en double pour valider la cohérence.
4. Cutover : DNS / config switch, monitoring intensif.

Semaines 5-6 : Cleanup

• Décommissionner Firebase (downgrade vers Spark plan, garder en lecture pour audit).
• Mettre à jour mentions légales / RGPD (changement de sous-traitant).
• Documenter le nouveau schéma + RLS policies.

Coût accompagnement Visionary : 5 600 à 17 500 € HT selon volume (nombre de collections, complexité du code, multi-tenant ou non, real-time ou non).

5. Choisissez Supabase si…

• Vous lancez un SaaS web standard (B2B ou B2C) et voulez tout-en-un.
• Vous voulez Postgres + Auth + Storage + Realtime sans assembler 4 services.
• Vous voulez RLS pour la sécurité multi-tenant.
• Vous voulez un prix prévisible (Pro $25/mois inclut beaucoup).
• Hébergement EU obligatoire (RGPD, secteur public).
• Vous voulez la portabilité Postgres (pouvoir déménager si besoin).

6. Choisissez Neon si…

• Vous travaillez en workflow Vercel et voulez une DB par preview environment.
• Vous lancez plusieurs micro-services qui auraient besoin de DB séparées (les branches Neon sont gratuites).
• Vos charges sont très intermittentes (le scale-to-zero gratuit fait sens).
• Vous gérez vous-même Auth + Storage ailleurs (vous voulez juste Postgres pur).
• Vous êtes confortable avec le risque de cold start (ou prêt à payer pour l'éviter).

7. Choisissez Firebase si…

• Vous développez une app mobile native (Flutter, iOS, Android) avec besoin temps-réel.
• Votre app a peu de logique business complexe — ce sont surtout des feeds temps-réel, des notifications, du chat.
• Vous êtes déjà dans l'écosystème Google Cloud Platform.
• Vous acceptez le coût variable + le verrouillage (sortie complexe).

La règle 2026 : Postgres par défaut, Firebase pour cas mobile temps-réel uniquement. Postgres a gagné la bataille du SaaS web. Le triplet Supabase + Next.js + Vercel est devenu le stack défaut français en 2026.

8. Pattern recommandé : Supabase + Drizzle + Next.js 15

Notre stack défaut chez Visionary pour les SaaS livrés en 2026 :

• Supabase Postgres pour la DB + Auth + Storage + Realtime (region Frankfurt pour RGPD).
• Drizzle ORM pour le schéma typé et les migrations (alternative moderne à Prisma, ~30 % plus rapide en runtime).
• RLS policies pour la sécurité multi-tenant.
• Next.js 15 App Router + Server Components pour le rendu serveur typé.
• Vercel pour le hosting (région Paris).

Setup typique en 1 journée pour un dev expérimenté : npm create supabase, schéma drizzle, push à Supabase, génération des types, premier composant qui fetch.

Exemple : query typée Drizzle + Supabase

// lib/db/schema.ts
import { pgTable, uuid, text, timestamp } from 'drizzle-orm/pg-core';

export const projects = pgTable('projects', {
  id: uuid('id').primaryKey().defaultRandom(),
  userId: uuid('user_id').notNull(),
  name: text('name').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

// app/projects/page.tsx (Server Component)
import { db } from '@/lib/db';
import { projects } from '@/lib/db/schema';
import { eq } from 'drizzle-orm';
import { verifySession } from '@/lib/dal';

export default async function ProjectsPage() {
  const { userId } = await verifySession();
  // RLS protège déjà côté DB, mais on filtre aussi explicitement
  const items = await db.select().from(projects).where(eq(projects.userId, userId));

  return (
    <ul>
      {items.map(p => <li key={p.id}>{p.name}</li>)}
    </ul>
  );
}

9. Mythes courants démontés

"Postgres ne scale pas" — faux

Postgres tient 100K+ writes/sec sur une instance dédiée moderne (16 vCPU). 99 % des SaaS n'atteindront jamais ces volumes. Si vous y arrivez, vous avez les ressources pour optimiser (indexes, partitioning, read replicas, Neon autoscaling). Stripe, Notion, OpenAI tournent sur Postgres.

"Firebase est plus simple à apprendre" — partiellement vrai

Le SDK Firebase est plus simple en apparence (pas de SQL à apprendre). Mais dès que nous dépassons les CRUD basiques, Firestore Security Rules + indexes composites + denormalization manuelle deviennent plus complexes que SQL. SQL est documenté, enseigné, audité depuis 50 ans. Le ROI d'apprentissage Postgres dépasse largement Firestore en 6 mois de pratique.

"Supabase, c'est juste un wrapper Postgres" — sous-estime la valeur

Supabase est en effet du Postgres, mais avec : Auth integrated, Storage S3-compatible, Realtime via WebSockets sur les changements de la DB, Edge Functions Deno, Vector embeddings, dashboard joli, RLS GUI. Reproduire tout cela soi-même prend 3-6 mois de dev. Supabase = stack SaaS complet.

10. Quoi tester avant de choisir

1. Cold start (Neon) : créer un compte free, attendre 5 min d'inactivité, mesurer le temps avant la première réponse.
2. Latence read/write : créer une table, insérer 1000 lignes, mesurer p50/p95/p99 lecture.
3. RLS : implémenter une policy multi-tenant simple, vérifier qu'un user ne peut pas voir les données d'un autre via l'API REST.
4. Migration : importer un dump de 100 MB, mesurer le temps.
5. DX : générer les types TypeScript depuis le schéma, voir si l'autocomplete vous plaît.
6. Coût simulé : entrer vos volumes attendus dans le tableur Visionary (lead magnet ci-dessus) ou dans les calculateurs officiels.

Questions fréquentes