Firebase vs Supabase
Googles umfassende Mobile-Plattform Firebase trifft auf Supabase, die Open-Source-Alternative auf PostgreSQL-Basis. Wofür sollte man sich bei der Wahl eines Backend-as-a-Service entscheiden?
Ein vollständiges Backend rund um Postgres: Auth, Storage, Realtime, Functions
Reines Serverless Postgres: Copy-on-Write-Branching, jetzt die Engine von Databricks
Das ist nicht die Frage „was ist besser“, sondern „was brauche ich“. Wenn du Auth, Storage, Realtime und Functions ausgereift von einer einzigen Plattform willst, wähle Supabase. Wenn du nur Postgres willst, mit Branch-per-PR und Abrechnung pro Compute-Sekunde, ist Neon stärker — Auth, Storage und Functions wurden am 17. September 2026 GA, haben aber eine deutlich kürzere Praxisgeschichte. Prisma/Drizzle funktionieren mit beiden; im Transaction-Mode des Poolers gibt es eine bekannte Inkompatibilität bei Prepared Statements, die eine zusätzliche Einstellung erfordert. Die Wahl des ORM bestimmt die Entscheidung nicht.
| Kategorie | Supabase | Neon |
|---|---|---|
| Performance | 8/10 | 8/10 |
| Erlernbarkeit | 8/10 | 7/10 |
| Ökosystem | 9/10 | 6/10 |
| Community | 9/10 | 6/10 |
| Arbeitsmarkt | 6/10 | 6/10 |
| Zukunftssicherheit | 8/10 | 7/10 |
// Supabase — RLS-geschützte Abfrage + Storage-Upload (TypeScript)
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.SUPABASE_URL!,
process.env.SUPABASE_ANON_KEY!
)
// Durch RLS-Policy "select_own_posts" geschützte Tabelle
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 im selben Projekt — signierte Upload-URL
const { data: uploadUrl } = await supabase.storage
.from('avatars')
.createSignedUploadUrl(`${userId}/profile.png`)
// Realtime — Live-Listening mit Postgres Changes
supabase
.channel('posts-changes')
.on(
'postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'posts' },
(payload) => console.log('Yeni post:', payload.new)
)
.subscribe()# Neon — CLI + Serverless-Treiber (bash + TypeScript)
# --- bash: Branch pro PR öffnen/löschen (CI-Schritt) ---
# 1) Sofortigen Copy-on-Write-Klon vom Hauptbranch erstellen
neon branches create \
--project-id $NEON_PROJECT_ID \
--name "preview/pr-${PR_NUMBER}" \
--parent main
# 2) Pooled Connection-String dieses Branches abrufen
neon connection-string "preview/pr-${PR_NUMBER}" --pooled
# 3) Branch nach Schließen des PR löschen (saubere Preview-Umgebung)
neon branches delete "preview/pr-${PR_NUMBER}" --project-id $NEON_PROJECT_ID
// --- TypeScript: HTTP-basierter Treiber in Serverless-Umgebung (Vercel Edge/Cloudflare Workers) ---
import { neon } from '@neondatabase/serverless'
const sql = neon(process.env.DATABASE_URL!) // pooled, hinter PgBouncer
const rows = await sql`
SELECT id, title, created_at
FROM posts
WHERE author_id = ${userId}
ORDER BY created_at DESC
LIMIT 20
`Das ist nicht die Frage „was ist besser“, sondern „was brauche ich“. Wenn du Auth, Storage, Realtime und Functions ausgereift von einer einzigen Plattform willst, wähle Supabase. Wenn du nur Postgres willst, mit Branch-per-PR und Abrechnung pro Compute-Sekunde, ist Neon stärker — Auth, Storage und Functions wurden am 17. September 2026 GA, haben aber eine deutlich kürzere Praxisgeschichte. Prisma/Drizzle funktionieren mit beiden; im Transaction-Mode des Poolers gibt es eine bekannte Inkompatibilität bei Prepared Statements, die eine zusätzliche Einstellung erfordert. Die Wahl des ORM bestimmt die Entscheidung nicht.
Kostenlose Beratung erhaltenKurze Antwort: Das hängt von deinem Bedarf ab. Willst du reines, verzweigbares Serverless Postgres mit minimalem Vendor-Lock-in, wähle Neon; willst du Auth, Storage, Realtime und Edge Functions fertig von einer Plattform, wähle Supabase. Die Entscheidung reduziert sich nicht auf „was ist populärer“, sondern auf „brauche ich eine Plattform oder nur eine Datenbank“.