Self-hosted PostgreSQL vs Supabase Vergleich

Läuft auf dem eigenen Server – eine seit 1986 gereifte relationale Open-Source-Datenbank

VS
Supabase

Eine verwaltete Open-Source-Backend-Plattform auf Basis von echtem PostgreSQL

17 Min. LesezeitDatenbank

Schnelles Fazit

Diese Entscheidung hat keine einzig richtige Antwort. Bist du ein kleines Team und hat Geschwindigkeit Priorität, ist Supabase die richtige Wahl: Auth, Storage, Realtime und Pooler sind vorhanden. Bei vorhersehbarer Last, einer Vorgabe zum Datenstandort (unter den 17 Regionen fehlt die Türkei) oder mit der Nutzerzahl wachsenden Kosten gewinnt selbst gehostetes PostgreSQL. Eine Warnung: Die offizielle Dokumentation schreibt, dass Managed Backup/PITR beim Self-Hosting entfällt — mit der Kontrolle erbst du den Restore-Test. Ein Backup anzulegen ist nicht das Kriterium; wiederherstellen zu können schon.

Self-hosted PostgreSQLSupabase
Vollständiges Fazit lesen

Punktevergleich

Diagramm wird geladen...

Detaillierte Bewertung

Detaillierte Bewertung: Self-hosted PostgreSQL und Supabase — Bewertungen pro Kategorie auf einer Skala von 1 bis 10
KategorieSelf-hosted PostgreSQLSupabase
Performance
8/10
8/10
Erlernbarkeit
5/10
8/10
Ökosystem
9/10
8/10
Community
9/10
9/10
Arbeitsmarkt
8/10
7/10
Zukunftssicherheit
8/10
8/10

Vor- und Nachteile

Self-hosted PostgreSQL

Vorteile

  • Die Software ist vollständig kostenlos (PostgreSQL License) — die Kosten sind an deine Infrastruktur gebunden
  • Volle Erweiterungsfreiheit: pgvector, PostGIS, pg_cron – installiere, was du willst
  • Die Daten bleiben physisch auf dem von dir gewählten Server — der Datenstandort liegt direkt in deiner Kontrolle
  • PITR ist eine Kernfunktion (WAL-Archivierung + pg_basebackup)
  • Kein Vendor-Lock-in — du befindest dich bereits auf deiner eigenen Infrastruktur
  • Jede Major-Version erhält 5 Jahre offiziellen Support — ein vorhersehbarer Patch-Zeitplan
  • RLS ist seit Version 9.5 eine Kernfunktion und lässt sich frei nach deinen Bedürfnissen einsetzen

Nachteile

  • Auth, Storage und Realtime sind nicht im Kern enthalten — sie müssen separat eingerichtet und betrieben werden
  • Für Connection Pooling ist ein separates Tool wie PgBouncer/Supavisor nötig
  • Backup/PITR/HA/Monitoring liegen vollständig in deiner Verantwortung — es gibt kein offizielles SLA
  • Die Lernkurve ist steiler: Auth, Pooling und HA manuell einzurichten kostet Zeit
  • Es gibt keine offizielle Seite mit Kundenreferenzen/Benchmarks (Community-Projekt)

Am besten geeignet für

Mittelgroße bis große Projekte mit festem, vorhersehbarem BudgetSysteme mit vertraglicher Pflicht zu Datenschutz/DatenstandortProjekte, die spezielle Erweiterungskombinationen wie pgvector/PostGIS benötigenTeams mit DevOps-Kapazität, die Restore-Tests fest einplanenLanglebige Projekte, bei denen Herstellerunabhängigkeit entscheidend ist

Supabase

Vorteile

  • Auth, Storage, Realtime und Data API sind bereits vorhanden — du schreibst die Auth-Schicht nicht von Grund auf neu
  • Der Free-Plan startet bei 0 $/Monat (500 MB DB, 5 GB Egress, 50.000 MAU)
  • Connection Pooling ist mit Dedicated-/Shared-Pooler-Optionen bereits integriert (Supavisor)
  • Fertige Compliance-Zertifizierungen wie HIPAA (BAA), ISO 27001, GDPR-DPA
  • Mit den Health Check Advisors wird die Fehlerrate der Dienste automatisch überwacht (September 2026)
  • Observability per Ein-Klick-Integration mit Grafana Cloud (Juli 2026)
  • Da darunter echtes PostgreSQL läuft, sind die Daten per pg_dump portierbar — der Vendor-Lock-in ist gering

Nachteile

  • Die Kosten wachsen mit zunehmender Nutzer-/Datenmenge stufenweise (0,125 $/GB Speicher, 0,09 $/GB Egress, 0,00325 $/MAU)
  • Unter den 17 Regionen ist die Türkei nicht vertreten — das wirft in Bezug auf den Datenschutz die Frage einer Auslandsübermittlung auf
  • Im Free-Plan gibt es kein automatisches Backup, im Pro-Plan nur 7 Tage
  • Erweiterungen sind auf den kuratierten Katalog der Plattform beschränkt — es gibt keine volle Freiheit auf Betriebssystemebene
  • Die Self-Hosting-Option ist 'community-supported' — es gibt kein offizielles SLA, und Managed Backup/PITR fallen weg

Am besten geeignet für

Schneller Einstieg von 0 auf 1 für Einzelentwickler oder kleine TeamsProduktteams, die Auth/Storage/Realtime nicht von Grund auf aufbauen wollenProjekte, die fertige Zertifizierungen wie HIPAA/ISO 27001/GDPR benötigenTeams, die verwaltetes Monitoring und automatische Fehlerraten-Alarme wünschenWer schnell starten und die Herstellerunabhängigkeit über pg_dump bewahren möchte

Code-Vergleich

Self-hosted PostgreSQL
# Self-hosted PostgreSQL - WAL-Archivierung + PITR-Einrichtung (postgresql.conf)
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /var/backups/pg_wal_archive/%f && cp %p /var/backups/pg_wal_archive/%f'
max_wal_senders = 3

# Basis-Backup erstellen (pg_basebackup)
pg_basebackup -D /var/backups/base -Ft -z -P -U replicator -h localhost

# PITR: Wiederherstellung auf einen bestimmten Zeitpunkt (recovery.signal + postgresql.conf)
# 1) Base-Backup in das Restore-Verzeichnis entpacken
# 2) Folgende Zeilen zu postgresql.conf hinzufügen, recovery.signal-Datei anlegen
restore_command = 'cp /var/backups/pg_wal_archive/%f %p'
recovery_target_time = '2026-09-23 09:00:00+03'

# pg_hba.conf - Verbindung nur vom Anwendungsserver
host    appdb    app_user    10.0.0.5/32    scram-sha-256

-- SQL (psql): Erweiterungsinstallation (volle Freiheit - self-host-spezifisch)
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS postgis;
CREATE EXTENSION IF NOT EXISTS pg_cron;

# Connection Pooling (PgBouncer, pgbouncer.ini)
[databases]
appdb = host=127.0.0.1 port=5432 dbname=appdb
[pgbouncer]
pool_mode = transaction
max_client_conn = 500
default_pool_size = 25
Supabase
-- SQL (Supabase SQL Editor): 1) Tabelle erstellen und RLS aktivieren (die Data API erfordert dies)
create table public.notes (
  id uuid default gen_random_uuid() primary key,
  user_id uuid references auth.users not null,
  content text not null,
  created_at timestamptz default now()
);
alter table public.notes enable row level security;

create policy "kullanicilar kendi notlarini okur"
  on public.notes for select
  using (auth.uid() = user_id);

create policy "kullanicilar kendi notlarini yazar"
  on public.notes for insert
  with check (auth.uid() = user_id);

// 2) Abfrage mit supabase-js (RLS wird automatisch angewendet)
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
)

const { data: notes, error } = await supabase
  .from('notes')
  .select('id, content, created_at')
  .order('created_at', { ascending: false })

// 3) Verbindungsstrings für den Postgres-Client (offizielle Tabelle "Endpoints and IP versions")
// Direct connection (persistenter Backend, pg_dump, Migration):
// postgresql://postgres:[YOUR-PASSWORD]@db.[PROJECT-REF].supabase.co:5432/postgres
// Dedicated pooler (nur Transaction-Modus, in kostenpflichtigen Plänen):
// postgresql://postgres:[YOUR-PASSWORD]@db.[PROJECT-REF].supabase.co:6543/postgres
// String manuell erstellen: aus dem Dashboard > Connect-Bildschirm kopieren (der Shared-Pooler-Host lässt sich nicht aus der Region ableiten).

Fazit

Diese Entscheidung hat keine einzig richtige Antwort. Bist du ein kleines Team und hat Geschwindigkeit Priorität, ist Supabase die richtige Wahl: Auth, Storage, Realtime und Pooler sind vorhanden. Bei vorhersehbarer Last, einer Vorgabe zum Datenstandort (unter den 17 Regionen fehlt die Türkei) oder mit der Nutzerzahl wachsenden Kosten gewinnt selbst gehostetes PostgreSQL. Eine Warnung: Die offizielle Dokumentation schreibt, dass Managed Backup/PITR beim Self-Hosting entfällt — mit der Kontrolle erbst du den Restore-Test. Ein Backup anzulegen ist nicht das Kriterium; wiederherstellen zu können schon.

Kostenlose Beratung erhalten
FAQ

Häufig gestellte Fragen

Da Supabase Standard-PostgreSQL verwendet, kannst du mit `pg_dump`/`pg_dumpall` oder über native Postgres-Replikation exportieren; die offizielle Dokumentation beschreibt die projektübergreifende Migration anhand eines Node.js-Skriptbeispiels (inklusive Auth/Storage). Supabase-spezifische Dienste wie Auth, Storage und Realtime auf der Self-Host-Seite neu aufzubauen (durch Betrieb des offiziellen Self-Host-Stacks mit Docker Compose) ist eine separate Aufgabe — Datenmigration und Herstellung der Dienstparität sind unterschiedliche Schritte.

Verwandte Blogartikel

Alle Artikel ansehen
Alle Vergleiche