Supabase oder eigenes Postgres? Eine ehrliche Entscheidungshilfe

Sobald ein Projekt eine Datenbank braucht, kommt früher oder später die Frage: „Reicht uns Supabase, oder brauchen wir ein eigenes Postgres?” Beide Antworten können richtig sein. Es kommt fast nie auf die Datenbankfähigkeiten an — Postgres ist Postgres — sondern auf das Drumherum.

Was Supabase neben Postgres mitbringt

Supabase ist im Kern ein gehosteter Postgres mit fünf Service-Layern obendrauf, die man sonst selbst bauen müsste:

• Auth mit E-Mail, OAuth, Magic Links und Multi-Factor.
• Realtime via Postgres-LISTEN/NOTIFY-Bridge — perfekt für Dashboards und kollaborative UIs.
• Storage für Dateien mit Row-Level-Security.
• Edge Functions für serverseitige Logik nahe an der Datenbank.
• Row-Level Security, die in der Datenbank lebt und für jedes Frontend gleich gilt.

Wenn ein Projekt drei oder mehr dieser Bausteine braucht, ist Supabase fast immer die effizientere Wahl.

Wann Supabase gewinnt

• Team unter fünf Entwicklern. Niemand will einen eigenen Auth-Stack pflegen.
• Multi-Tenant-SaaS. RLS in der Datenbank ist die sauberste Lösung — und Supabase pusht einen direkt in diese Richtung.
• Realtime-UIs ohne separates WebSocket-Backend.
• EU-Region wählbar — DSGVO ohne Schmerz.
• Schnelles Anfangen: das erste lauffähige Backend in unter einer Stunde.

Wann eigenes Postgres gewinnt

• Custom SQL-Operations, die Supabase-Limits sprengen (lange Materialized Views, schwere Stored Procedures, eigene Background Workers).
• Spezielle Postgres-Extensions außerhalb dessen, was Supabase aktiviert hat (z. B. eigene TimescaleDB-Hyperfunctions, PL/Python).
• Compliance schreibt einen bestimmten Anbieter oder On-Premise vor.
• Kosten ab gewisser Skalierung: bei einigen Millionen aktiven Zeilen und konstantem Realtime-Traffic kann eine eigene Hetzner-Maschine günstiger sein.
• Air-gapped Setups — wenn die Datenbank nie ins offene Internet darf.

Die unterschätzte Hybrid-Option

In mehreren Projekten habe ich beides kombiniert: Supabase als Auth-Provider und Daten-Layer für 90 % der Tabellen, plus ein dediziertes Postgres für Workloads, die sich dort nicht abbilden lassen — etwa Zeitreihen-Daten mit TimescaleDB-Hyperfunctions.

Der Aufwand für die Verkabelung ist überschaubar: Service-Account, separates Connection-Pool-Setup, fertig.

Eine Heuristik

> if (team_size < 5 && multi_tenant) → Supabase
> if (heavy_custom_sql || on_prem) → eigenes Postgres
> if (realtime_ui && low_complexity) → Supabase
> if (kostensensitiv && skalierend) → Supabase erst, später migrieren
> else → das Team fragen, was es lieber pflegt

Die letzte Zeile ist die wichtigste. Eine Datenbank, die niemand im Team versteht, ist langfristig teurer als die theoretisch bessere Wahl.

Migration ist nicht so schmerzhaft wie gedacht

Eine Migration von Supabase zu eigenem Postgres ist gut machbar (pg_dump läuft genauso wie sonst). Die Reibung liegt nicht in den Daten, sondern in Auth- und Storage-Modulen, die dann selbst gebaut werden müssen. Wer die Migration als realistische Option im Hinterkopf hat, kann Supabase guten Gewissens für die ersten Jahre wählen.

In meiner Praxis: 80 % der Projekte starten und bleiben auf Supabase. 15 % wechseln nach Jahren wegen sehr spezifischer Anforderungen. 5 % waren von Anfang an in der eigenen-Postgres-Welt — meistens wegen regulatorischer Vorgaben, fast nie wegen technischer.