Firebase vs Supabase
La plateforme mobile complète de Google, Firebase, face à Supabase, l'alternative PostgreSQL open-source. Que privilégier dans le choix d'un Backend-as-a-Service ?
Un backend complet autour de Postgres : auth, storage, realtime, functions
Postgres serverless pur : branching copy-on-write, désormais le moteur de Databricks
Ce n'est pas une question de "lequel est meilleur", mais de "ce dont j'ai besoin". Si tu veux Auth+Storage+Realtime+Functions mature sur une seule plateforme, choisis Supabase. Si tu veux uniquement Postgres + branch-per-PR + facturation à la seconde de calcul, Neon est plus fort — Auth/Storage/Functions sont passés en disponibilité générale le 17 septembre 2026, mais leur historique de terrain est bien plus court. Prisma/Drizzle fonctionnent avec les deux ; le mode transaction du pooler présente une incompatibilité connue des prepared statements qui exige un réglage supplémentaire. Le choix de l'ORM ne détermine pas la décision.
| Catégorie | Supabase | Neon |
|---|---|---|
| Performance | 8/10 | 8/10 |
| Facilité d'apprentissage | 8/10 | 7/10 |
| Écosystème | 9/10 | 6/10 |
| Communauté | 9/10 | 6/10 |
| Marché de l'emploi | 6/10 | 6/10 |
| Pérennité | 8/10 | 7/10 |
// Supabase — Requête protégée par RLS + upload Storage (TypeScript)
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.SUPABASE_URL!,
process.env.SUPABASE_ANON_KEY!
)
// Table protégée par la politique RLS "select_own_posts"
const { data: posts, error } = await supabase
.from('posts')
.select('id, title, created_at')
.eq('author_id', userId)
.order('created_at', { ascending: false })
.limit(20)
if (error) throw error
// Storage dans le même projet — URL d'upload signée
const { data: uploadUrl } = await supabase.storage
.from('avatars')
.createSignedUploadUrl(`${userId}/profile.png`)
// Realtime — écoute en direct via Postgres Changes
supabase
.channel('posts-changes')
.on(
'postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'posts' },
(payload) => console.log('Nouveau post:', payload.new)
)
.subscribe()# Neon — CLI + driver serverless (bash + TypeScript)
# --- bash : ouvrir/supprimer une branche par PR (étape CI) ---
# 1) Créer un clone copy-on-write instantané depuis la branche principale
neon branches create \
--project-id $NEON_PROJECT_ID \
--name "preview/pr-${PR_NUMBER}" \
--parent main
# 2) Récupérer la connection string poolée de cette branche
neon connection-string "preview/pr-${PR_NUMBER}" --pooled
# 3) Supprimer la branche à la fermeture de la PR (environnement preview propre)
neon branches delete "preview/pr-${PR_NUMBER}" --project-id $NEON_PROJECT_ID
// --- TypeScript : dans un environnement serverless (Vercel Edge/Cloudflare Workers), driver HTTP ---
import { neon } from '@neondatabase/serverless'
const sql = neon(process.env.DATABASE_URL!) // poolé, derrière PgBouncer
const rows = await sql`
SELECT id, title, created_at
FROM posts
WHERE author_id = ${userId}
ORDER BY created_at DESC
LIMIT 20
`Ce n'est pas une question de "lequel est meilleur", mais de "ce dont j'ai besoin". Si tu veux Auth+Storage+Realtime+Functions mature sur une seule plateforme, choisis Supabase. Si tu veux uniquement Postgres + branch-per-PR + facturation à la seconde de calcul, Neon est plus fort — Auth/Storage/Functions sont passés en disponibilité générale le 17 septembre 2026, mais leur historique de terrain est bien plus court. Prisma/Drizzle fonctionnent avec les deux ; le mode transaction du pooler présente une incompatibilité connue des prepared statements qui exige un réglage supplémentaire. Le choix de l'ORM ne détermine pas la décision.
Obtenir une consultation gratuiteRéponse courte : ça dépend de ton besoin. Si tu veux un Postgres serverless pur et branchable avec un minimum de dépendance fournisseur, choisis Neon ; si tu veux auth, storage, realtime et edge functions prêts sur une seule plateforme, choisis Supabase. La décision ne se résume pas à "lequel est populaire" mais à "ai-je besoin d'une plateforme ou juste d'une base de données".